Re: Message length and caches

I'm guessing you mean for non-chunked transfers.

imho frame-by-connection-closed should be avoided whenever possible. It is
evil, evil, evil, and causes many corrupted downloads.
I don't think it is particularly paranoid to ignore such responses in a
cache, should they show up, and believe that not re-chunking is
reasonable... however, it gets more interesting in an HTTP/2.0 world (where
we'd instead probably have to indicate that the other side is doing
something stupid).
-=R


On Sun, Nov 25, 2012 at 11:35 PM, Willy Tarreau <w@1wt.eu> wrote:

> Hi,
>
> When there is no explicit body length in a message, it is terminated by
> closing the connection. As we all know, this causes some ambiguity for
> the client because it doesn't know whether a response body is complete
> or was truncated by anything along the path, including timeouts. Thus
> I'm wondering if some caches make a difference between such responses
> or not (eg: a cache could decide not to cache objects terminated this
> way).
>
> The reason is that we recently implemented support for gzip compression
> in haproxy and I preferred not to add an explicit response end to
> messages which did not have one for the reason above. This results in
> not compressing such responses at all (since we would not emit the
> trailing gzip header with crc, making all responses appear as truncated).
>
> Do some people think that this practice is paranoid ? Maybe after all
> we could compress and chunk responses and make the client be certain
> that the message is complete while we were not. It just makes me feel
> a bit like lying to the client.
>
> Depending on common practices and opinion, I think that we could add
> a small paragraph in -p1 about this (eg: intermediaries should not
> re-chunk a close-delimited response).
>
> Regards,
> Willy
>
>
>