I can't find there an (sami)automatic way to manage HTTP/1.0 vs HTTP/1.1 compatibility? Example I have a client that supports HTTP/1.0 only and I need to transfer an unknown amount of data. Now as one who writes the server I need to check the clients protocol and choose chucked transfer encoding with possibility to keep connection keep alive or close one after data transfer using socket shutdown. Shouldn't this kind of stuff should be handled automatically or sami-automatically? Keep alive semantics between HTTP/1.0 and HTTP/1.1 is tricky and it is very easy to make a mistake. Also note I tested some of your examples and found that they responding with HTTP/1.1 on HTTP/1.0 requests. Artyom
On Mon, Jul 3, 2017 at 11:47 AM, Artyom Beilis via Boost
I can't find there an (sami)automatic way to manage HTTP/1.0 vs HTTP/1.1 compatibility?
Some of it is automatic but the keep-alive is not.
Example I have a client that supports HTTP/1.0 only and I need to transfer an unknown amount of data. Now as one who writes the server I need to check the clients protocol and choose chucked transfer encoding with possibility to keep connection keep alive or close one after data transfer using socket shutdown.
HTTP/1.0 doesn't support the chunked transfer encoding, but this scenario is handled by Beast. The behavior depends on the Body type you are using with the stream operation, and the message::prepare_payload function. Here is a breakdown: * If the Body knows the payload size, A call to message::prepare_payload will set Content-Length and clear chunked Transfer-Encoding if present * If the Body does not know the payload size, and the version is HTTP/1.1 then message::prepare_payload will set chunked Transfer-Encoding, and clear Content-Length if set. * If the Body does not know the payload size, and the version is HTTP/1.0 then message::prepare_payload will clear chunked Transfer-Encoding if set, and clear Content-Length if set. During a serialization stream operation (i.e. write, async_write): * If the message is version HTTP/1.1 and the Connection field includes the "close" token, when the stream write operation is complete the error http::stream_closed will be delivered. This indicates to the caller that the connection should be closed * If the message is version HTTP/1.0 and the Connection field does not include the "keep-alive" token, when the stream write operation is complete the error http::stream_closed will be delivered. This indicates to the caller that the connection should be closed * If the message is version HTTP/1.0 and the Content-Length field is not set, then when the stream write operation is complete the error http::stream_closed will be delivered. This indicates to the caller that the connection should be closed.
Shouldn't this kind of stuff should be handled automatically or sami-automatically?
Beast could probably do a tiny bit more, for example I should probably add these signatures to http::message bool keep_alive() const; void keep_alive(bool should_keep_alive) const; There are 1 or 2 other small quality-of-life members I will add to message, they have not been written yet.
Also note I tested some of your examples and found that they responding with HTTP/1.1 on HTTP/1.0 requests.
I didn't want to bloat the example with boring code to handle the differences but after some discussion on the Slack I realize that the examples need to be great, because most users are going to just copy and paste them. This is something that I will certainly address. Probably when I find myself repeating code in the example I will be motivated to improve message's public interfaces to make it easier. By the way I very much appreciate your analysis! Thanks
participants (2)
-
Artyom Beilis
-
Vinnie Falco