On 4 November 2015 at 20:25, Bert Huijben <b...@qqmail.nl> wrote: >> -----Original Message----- >> From: Ivan Zhakov [mailto:i...@visualsvn.com] >> Sent: woensdag 4 november 2015 16:29 >> To: Bert Huijben <b...@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 <b...@qqmail.nl> wrote: >> >> -----Original Message----- >> >> From: Ivan Zhakov [mailto:i...@visualsvn.com] >> >> Sent: woensdag 4 november 2015 15:50 >> >> To: Bert Huijben <b...@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 <b...@qqmail.nl> wrote: >> >> >> -----Original Message----- >> >> >> From: rhuij...@apache.org [mailto:rhuij...@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
