serf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bert Huijben <>
Subject RE: svn commit: r1715431 - in /serf/trunk: buckets/response_buckets.cserf_bucket_types.h test/test_buckets.c
Date Sat, 21 Nov 2015 20:35:31 GMT
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

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 and a few other sites.


Sent from Outlook Mail for Windows 10 phone

From: Ivan Zhakov
Sent: zaterdag 21 november 2015 18:40
To: Bert Huijben
Subject: Re: svn commit: r1715431 - in /serf/trunk: buckets/response_buckets.cserf_bucket_types.h

On 21 November 2015 at 19:55, Bert Huijben <> wrote:
>> -----Original Message-----
>> From: Ivan Zhakov []
>> Sent: zaterdag 21 november 2015 17:00
>> To:
>> Cc:
>> 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,  <> wrote:
>> > Author: rhuijben
>> > Date: Fri Nov 20 22:09:46 2015
>> > New Revision: 1715431
>> >
>> > URL:
>> > 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
> 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...
> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message