On Mon, Jul 3, 2017 at 11:47 AM, Artyom Beilis via Boost <boost@lists.boost.org> wrote:
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