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