I’m guessing almost every current user is only interested in the final status and wants to ignore the intermediate statee values. In general you want to register some special handler for the intermediate status values.
The auth layer for 401/407… which are not strictly intermediate but can be handled like that. 101 by a protocol upgrade handler. 100 by special hooks that want to know if a request got through the parsing phase before the actual response can be determined after some expensive processing. The old wait for handlers will still do the right thing and tell you if the request succeeded and that you can expect a body now. My recent testing showed that 0 byte bodies are becoming more common on certain error statee where there used to be a html explanation before. (301, 307)…. Wasted quite some time trying to find out why serf-get didn’t show anything on intel.com and a few other sites. Bert Sent from Outlook Mail for Windows 10 phone From: Ivan Zhakov Sent: zaterdag 21 november 2015 18:40 To: Bert Huijben Cc: rhuij...@apache.org;dev@serf.apache.org Subject: Re: svn commit: r1715431 - in /serf/trunk: buckets/response_buckets.cserf_bucket_types.h test/test_buckets.c On 21 November 2015 at 19:55, Bert Huijben <b...@qqmail.nl> wrote: >> -----Original Message----- >> From: Ivan Zhakov [mailto:i...@visualsvn.com] >> Sent: zaterdag 21 november 2015 17:00 >> To: rhuij...@apache.org >> Cc: dev@serf.apache.org >> Subject: Re: svn commit: r1715431 - in /serf/trunk: >> buckets/response_buckets.c serf_bucket_types.h test/test_buckets.c >> >> On 21 November 2015 at 01:09, <rhuij...@apache.org> wrote: >> > Author: rhuijben >> > Date: Fri Nov 20 22:09:46 2015 >> > New Revision: 1715431 >> > >> > URL: http://svn.apache.org/viewvc?rev=1715431&view=rev >> > Log: >> > Allow a response to handle multiple sets of headers for a single request. >> > This enables support for http statee like 100 'Continue'. >> > >> Hi Bert, >> >> Thanks for fixing this long-standing problem! >> >> > >> > * buckets/response_buckets.c >> > (response_context_t): Hold two sets of headers. >> > (serf_bucket_response_create): Tweak init. >> > (serf_bucket_response_get_headers): Get the fetch headers. >> > (serf_response_destroy_and_data): Update cleanup. >> > (parse_status_line): Allow parsing another statusline. >> > (fetch_headers): Store new headers in incoming headers. >> > (run_machine): Handle new states. >> > >> > (serf_bucket_response_wait_for_some_headers): New function. >> > +apr_status_t serf_bucket_response_wait_for_some_headers( >> > + serf_bucket_t *bucket, >> > + int wait_for_next) >> >> I've two questions about this function: >> - What is the purpose of wait_for_next parameter? >> - May be better API would be >> serf_bucket_response_for_headers2(serf_bucket_t *bucket, int >> ignore_interim_status) ? I > > I intend to change that a bit later (probably tomorrow or Monday). I think we > need to split this in two functions. > OK, I'll wait for further commits. But currently I think it would be better to have serf_bucket_response_for_headers2() and deprecate serf_bucket_response_for_headers() to encourage API users to revise they usage of this function in terms whether they want to handle interim responses or not. > Currently with FALSE it waits until there is some set of headers available. > If there is > one it returns directly. > > While with TRUE it stops looking at the current set of headers if it is not > the set of > final headers... and then waits for the next set of headers. (final or not) > > > I intend to replace the current auth code that currently uses +- > wait_for_headers() and > only then starts forwarding to the normal response code, to use a similar > approach... But > then replace the stream below the response bucket with that of the new > response after > sending the request with the right headers. > Yes, current auth code will mask interim responses since it waits for final headers. > This code already assumes that the bucket is really a response bucket and can > do the > right thing. (I think we should check this condition though... and don't > apply auth > functions (and 99% chance segfault) if it is not a normal response bucket) > > > And when we do that... we can also use 100% this same approach for sending a > HTTP/1 request, upgrade to http/2 (first 101 header-set) ... and handle the > final set > of headers+body as HTTP/2. > I'm not sure that I'm fully understand you plan, but I'm very interested to see this code :) -- Ivan Zhakov
