Discussion:
[boost] [Beast] HTTP/1.0 Protocol compatibility
Artyom Beilis via Boost
2017-07-03 18:47:06 UTC
Permalink
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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Vinnie Falco via Boost
2017-07-03 19:06:03 UTC
Permalink
On Mon, Jul 3, 2017 at 11:47 AM, Artyom Beilis via Boost
Post by 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.
Post by Artyom Beilis via Boost
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.
Post by Artyom Beilis via Boost
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.
Post by Artyom Beilis via Boost
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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Loading...