Re: [boost] [Beast] HTTP/1.0 Protocol compatibility

Subject: Re: [boost] [Beast] HTTP/1.0 Protocol compatibility
From: Vinnie Falco (vinnie.falco_at_[hidden])
Date: 2017-07-03 19:06:03

On Mon, Jul 3, 2017 at 11:47 AM, Artyom Beilis via Boost
<boost_at_[hidden]> 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