serf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ivan Zhakov <i...@visualsvn.com>
Subject Re: svn commit: r1712559 - /serf/trunk/test/test_buckets.c
Date Wed, 04 Nov 2015 17:40:14 GMT
On 4 November 2015 at 20:25, Bert Huijben <bert@qqmail.nl> wrote:
>> -----Original Message-----
>> From: Ivan Zhakov [mailto:ivan@visualsvn.com]
>> Sent: woensdag 4 november 2015 16:29
>> To: Bert Huijben <bert@qqmail.nl>
>> Cc: dev@serf.apache.org
>> Subject: Re: svn commit: r1712559 - /serf/trunk/test/test_buckets.c
>>
>> On 4 November 2015 at 17:52, Bert Huijben <bert@qqmail.nl> wrote:
>> >> -----Original Message-----
>> >> From: Ivan Zhakov [mailto:ivan@visualsvn.com]
>> >> Sent: woensdag 4 november 2015 15:50
>> >> To: Bert Huijben <bert@qqmail.nl>
>> >> Cc: dev@serf.apache.org
>> >> Subject: Re: svn commit: r1712559 - /serf/trunk/test/test_buckets.c
>> >>
>> >> On 4 November 2015 at 17:47, Bert Huijben <bert@qqmail.nl> wrote:
>> >> >> -----Original Message-----
>> >> >> From: rhuijben@apache.org [mailto:rhuijben@apache.org]
>> >> >> Sent: woensdag 4 november 2015 15:46
>> >> >> To: dev@serf.apache.org
>> >> >> Subject: svn commit: r1712559 - /serf/trunk/test/test_buckets.c
>> >> >>
>> >> >> Author: rhuijben
>> >> >> Date: Wed Nov  4 14:45:54 2015
>> >> >> New Revision: 1712559
>> >> >>
>> >> >> URL: http://svn.apache.org/viewvc?rev=1712559&view=rev
>> >> >> Log:
>> >> >> * test/test_buckets.c
>> >> >>   (test_buckets): Following up on r1712557, remove accidentally
added
>> >> test
>> >> >>     reference.
>> >> >
>> >> > This was accidentally left from the attached patch that I wrote as
one of
>> the
>> >> options to properly handle 100 and 101 status codes. (Followup on an irc
>> >> discussion yesterday)
>> >> >
>> >> > Patch attached.
>> >> >
>> >> I don't see patch attached.
>> >
>> > I do see the attachment, but perhaps the list filters it and gmail just shows
>> me whatever I sent.
>> >
>> > The attachment is also on https://lpt1.nl/f/2015/201511-serf-1xx-
>> responses.patch
>> >
>> I was thinking about the same approach first (teaching response bucket
>> handle 1xx responses), but currently I am inclined that interim
>> responses should be separate response bucket instances handled via
>> separate callback, if serf API users is going to handle them.
>
> The problem with that is that it doesn't match how the buckets are constructed that read
the data.
>
> The response bucket is created by the application and then read by the application. Only
> at EOF it falls back (Via the barrier) to the connection, which at that points asks the
next
> request to create a new response bucket.
>
We already have situation when application creates response bucket,
but it handled by serf without application knowledge during
authentication. We can do the same for 1xx responses: handle them at
serf layer at switch protocol if needed.

> The other option would be to do things like http2: handle the connection at a higher
layer...
> and only hand of requests that can't ready any further than the data they are allowed.
> (Luckily in http2 you don't have to parse through the actual headers to do this filtering...
> the framing layer handles that).
>
>
> To implement the handling of the earlier responses we would probably need a completely
> different request+response setup. Handling them as a separate callback can be done,
> but it will also move away from the documented handling by the RFCs; especially
> the newer ones.
>
> From HTTP/2:
> https://httpwg.github.io/specs/rfc7540.html#rfc.section.8.1
> [[
> An HTTP message (request or response) consists of:
> 1.for a response only, zero or more HEADERS frames (each followed by zero or more CONTINUATION
frames) containing the message headers of informational (1xx) HTTP responses (see [RFC7230],
Section 3.2 and [RFC7231], Section 6.2),
> 2.one HEADERS frame (followed by zero or more CONTINUATION frames) containing the message
headers (see [RFC7230], Section 3.2),
> 3.zero or more DATA frames containing the payload body (see [RFC7230], Section 3.3),
and
> 4.optionally, one HEADERS frame, followed by zero or more CONTINUATION frames containing
the trailer-part, if present (see [RFC7230], Section 4.1.2).
> ]]
>
The seems to be very similar to documented 1xx response handling in HTTP/1.1

> https://httpwg.github.io/specs/rfc7231.html#rfc.section.5.1.1
> [[
> •A client MUST NOT generate a 100-continue expectation in a request that does not include
a message body.
> •A client that will wait for a 100 (Continue) response before sending the request message
body MUST send an Expect header field containing a 100-continue expectation.
> •A client that sends a 100-continue expectation is not required to wait for any specific
length of time; such a client MAY proceed to send the message body even if it has not yet
received a response. Furthermore, since 100 (Continue) responses cannot be sent through an
HTTP/1.0 intermediary, such a client SHOULD NOT wait for an indefinite period before sending
the message body.
> •A client that receives a 417 (Expectation Failed) status code in response to a request
containing a 100-continue expectation SHOULD repeat that request without a 100-continue expectation,
since the 417 response merely indicates that the response chain does not support expectations
(e.g., it passes through an HTTP/1.0 server).
> ]]
> [[
> Requirements for servers:
> •A server that receives a 100-continue expectation in an HTTP/1.0 request MUST ignore
that expectation.
> •A server MAY omit sending a 100 (Continue) response if it has already received some
or all of the message body for the corresponding request, or if the framing indicates that
there is no message body.
> •A server that sends a 100 (Continue) response MUST ultimately send a final status
code, once the message body is received and processed, unless the connection is closed prematurely.
> •A server that responds with a final status code before reading the entire message
body SHOULD indicate in that response whether it intends to close the connection or continue
reading and discarding the request message (see Section 6.6 of [RFC7230]).
> ]]
>
> I especially like the / has not yet been rejected by the server / part of this one :-)
> https://httpwg.github.io/specs/rfc7231.html#rfc.section.6.2.1
> [[
>
> The 100 (Continue) status code indicates that the initial part of a request has been
received
> and has not yet been rejected by the server. The server intends to send a final response
> after the request has been fully received and acted upon.
>
>
> When the request contains an Expect header field that includes a 100-continue
> expectation, the 100 response indicates that the server wishes to receive the request
> payload body, as described in Section 5.1.1. The client ought to continue sending the
> request and discard the 100 response.
>
>
> If the request did not contain an Expect header field containing the 100-continue
> expectation, the client can simply discard this interim response.
> ]]
>
As far I remember Expect 100-continue useless in HTTP/1.1 and clients
cannot rely on them to prevent sending request body: they still
required to send request body. Also there is no guarantee for HTTP 100
Continue status if client added Expect: 100-Continue and clients
should fallback to sending request body after some timeout.


-- 
Ivan Zhakov

Mime
View raw message