httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <minf...@sharp.fm>
Subject Re: svn commit: r1482918 - in /httpd/httpd/trunk: modules/http/http_filters.c server/protocol.c
Date Mon, 18 May 2015 10:08:02 GMT
On 25 Jul 2013, at 10:16 PM, Rainer Jung <rainer.jung@kippdata.de> wrote:

> I have a question about this part which turned up when debugging a
> mod_deflate test failure. Bear with me and my very incomplete
> understanding of bucket brigades:
> 
> Is this error bucket insertion safe? In the mod_deflate test we added
> spurious data to the end of a compressed request body. When processing
> the request, mod_deflate inflated the request body and mod_echo_post
> returned it. If the body was big enough the echoed data appeared at the
> client. Now the spurious data was seen by mod_deflate and the above
> error bucket inserted. This error did not show up on the client side.
> 
> Now the test case received a connection close header directly at the
> beginning of the response, but I wonder what would have happened if this
> had been a keep-alive connection. Would the error bucket have been
> queued and returned in front of the next response? Or would the
> connection have been aborted by the server in any case? I'm a little bit
> nervous here because of the potential for response mixup.
> 
> If the posted body was small enough that the spurious data was found
> before the first part of the response as sent out, then the server
> correctly returns the 400 error page instead of the echo response.

(Coming back to this).

The error buckets are metadata buckets, and they are inserted before the EOS in the stream.
Buckets are processed in order, for there to be a response splitting problem the error bucket
will need to appear after the EOS.

In the case of mod_deflate’s input filter, it does not seem to take any notice of an error
bucket (or any meta buckets), and so is likely to silently consume the error bucket (which
is of zero length).

I suspect previously the core was silently swallowing errors, and now that this is fixed mod_deflate
is now silently swallowing errors. It looks like mod_deflate needs to be fixed, but it doesn’t
affect the underlying patch (from what I can see).

Regards,
Graham
—


Mime
View raw message