On Mon, Jan 20, 2014 at 07:06:06AM +0100, Baptiste wrote:
> Hi Taylor,
>
> Here is how I would do.
> Create a specific backend for the specific PDF download URLs and add the
> lines below in it:
> tcp-response inspect-delay 5s
> tcp-response content reject unless { res.payload(0,4) -m bin 25504446 }
It will not work. This will apply to the start of the response which is
the HTTP headers.
Currently, the only HTTP body analyser we have is on the request path
and is done *after* header processing, which means that we cannot use
it for that purpose (which is why I'm often saying we need to change
that in the future).
However, I think that for some special purpose sampling, we could write
a few parsers which would wait for some payload *after* the body. The
difficulty is that we have not yet parsed the content-length nor even
the response status or transfer-encoding. But probably that for *some*
specific cases we could start by having a simple parser which waits for
a given amount of bytes.
I'd also like to see if we could write a generic parser which would
overlap with some of the existing processing but would significantly
help : it would be used in TCP rules to wait for a complete body to
be present in the message, either the same amount of bytes as the
content-length, or a full buffer, or a close or the finishing zero
in case of chunked encoding. We could use this to ensure that anything
past that rule would be parsable.
But for the short term I have no reliable solution unfortunately.
Regards,
Willy
