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) Bert Sent from Outlook Mail for Windows 10 phone From: Greg Stein Sent: maandag 21 december 2015 02:20 To: Bert Huijben Cc: dev@serf.apache.org Subject: Re: svn propchange: r1720339 - svn:log On Sat, Dec 19, 2015 at 3:08 PM, <rhuij...@apache.org> 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? Cheers, -g
