serf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bert Huijben <>
Subject RE: svn propchange: r1720339 - svn:log
Date Mon, 21 Dec 2015 09:34:46 GMT
Read bucket was already implemented on the aggregate bucket for some releases.

There it checks if the first bucket is of that type …and if it is it removes it from the
aggregate (splitting head and tail) + returns it.

Using it just as a fetch and keep in wrappers would be incompatible, I think?

(After a lot of research I actually started using this where we read headers, that might be
read from a headers bucket… Case triggered on http2 where we convert compressed headers
to normal headers for processing by the usual bucket code)


Sent from Outlook Mail for Windows 10 phone

From: Greg Stein
Sent: maandag 21 december 2015 02:20
To: Bert Huijben
Subject: Re: svn propchange: r1720339 - svn:log

On Sat, Dec 19, 2015 at 3:08 PM, <> wrote:

> +* src/outgoing_request.c
> +    Move file here.
> +  (serf__handle_response): Accidental early commit of a verification
> +    that we are actually calling against a response instance instead
> +    of some other bucket wrapping a response (which would cause a
> +    segfault on the further calls)

Hmm. This might be the first use for the read_bucket() call... if the
caller needs a RESPONSE bucket, but might be looking at a wrapper, then it
can use read_bucket to get the RESPONSE.

Maybe our wrappers should start implementing read_bucket ?

On the other hand, what wrapper might be in there, and what problems might
ensue by "unwrapping" the RESPONSE?


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