> -----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. 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). ]] 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. ]] Bert
