serf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bert Huijben" <>
Subject RE: svn commit: r1712559 - /serf/trunk/test/test_buckets.c
Date Wed, 04 Nov 2015 17:25:26 GMT

> -----Original Message-----
> From: Ivan Zhakov []
> Sent: woensdag 4 november 2015 16:29
> To: Bert Huijben <>
> Cc:
> Subject: Re: svn commit: r1712559 - /serf/trunk/test/test_buckets.c
> On 4 November 2015 at 17:52, Bert Huijben <> wrote:
> >> -----Original Message-----
> >> From: Ivan Zhakov []
> >> Sent: woensdag 4 november 2015 15:50
> >> To: Bert Huijben <>
> >> Cc:
> >> Subject: Re: svn commit: r1712559 - /serf/trunk/test/test_buckets.c
> >>
> >> On 4 November 2015 at 17:47, Bert Huijben <> wrote:
> >> >> -----Original Message-----
> >> >> From: []
> >> >> Sent: woensdag 4 november 2015 15:46
> >> >> To:
> >> >> Subject: svn commit: r1712559 - /serf/trunk/test/test_buckets.c
> >> >>
> >> >> Author: rhuijben
> >> >> Date: Wed Nov  4 14:45:54 2015
> >> >> New Revision: 1712559
> >> >>
> >> >> URL:
> >> >> 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
> 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
> 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

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.

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:
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), HEADERS frame (followed by zero or more CONTINUATION frames) containing the message
headers (see [RFC7230], Section 3.2), 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).
•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
•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 :-)

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.


View raw message