Re: Message length and caches

Roy--

That definitely solves part of the problem (there really need to be two
status codes, one for the server and one for the point-to-point
connection), but for a caching intermediary, it would like to know up-front
if it should bother to put that data into the cache. I know that I wouldn't
want to put anything framed with connection closed into the cache, and so
having something propagate the nature of the worst point-to-point framing
is probably useful.

-=R


On Mon, Nov 26, 2012 at 3:03 PM, Roy T. Fielding <fielding@gbiv.com> wrote:

> In waka, each message ends with an 8bit status code -- it is
> either the same as that given in the beginning or a new code if the
> message was sent incomplete (on a request, it is used to indicate that
> an upload is being aborted).  I send the entire code because I want
> to distinguish between "origin closed connection" and "intermediary
> timed out waiting for more data from origin".  I assume that something
> similar could be accomplished in SPDY by ending the last frame with
> some sort of unexpected upstream termination bit.
>
> ....Roy
>
> On Nov 26, 2012, at 2:36 PM, Adrien W. de Croy wrote:
>
>
> in the case I was talking about, the intermediary already chunked the
> data.  So it really has no option when the server closes.  It can't close
> to the client without sending a 0 chunk, since that would turn a
> potentially complete resource into an aborted one.  So it must send the 0
> chunk.
>
> Unless you're going to say any time the intermediary expects the server to
> close it should not chunk the data to the client.
>
> I think we're just stuck with this until 1.2 or 2.0 deprecates the
> mechanism completely.  Has it really been that big a problem?
>
> Adrien
>
> ------ Original Message ------
> From: "Roberto Peon" <grmocg@gmail.com>
> To: "Adrien W. de Croy" <adrien@qbik.com>
> Cc: "Willy Tarreau" <w@1wt.eu>;"HTTP Working Group" <ietf-http-wg@w3.org>
> Sent: 26/11/2012 11:23:30 p.m.
> Subject: Re: Message length and caches
>
> I was understanding that Willy was suggesting that we potentially add a
> recommendation (or stronger) about what an intermediary should do when it
> has a response which is framed by connection close.
> Specifically, if a response is framed by connection close, then, treat the
> response as if it was uncacheable and attempt to convey to the client that
> the originator of the response framed with connection close.
> That indication could be accomplished by also framing with connection:
> close, or it could take the form (if we extend the spec) of a new header of
> some kind.
> -=R
>
>
> On Mon, Nov 26, 2012 at 12:09 AM, Adrien W. de Croy < <adrien@qbik.com>
> adrien@qbik.com> wrote:
>
>> Hi Willy
>>
>> it actually gets worse than this.
>>
>> Some intermediaries chunk emitted data if the server indicated it would
>> close and sends no C-L (so that the intermediary can keep the client
>> connection alive).
>>
>> Since that intermediary can't tell the difference between an abortive and
>> normal close, it will send a 0 chunk on close.
>>
>> So the receiver of that message will never know what happened.
>>
>> So I agree with Roberto about use of TCP close as a protocol signal, but
>> we're stuck with it.
>>
>> Adrien
>>
>>
>>
>> ------ Original Message ------
>> From: "Willy Tarreau" < <w@1wt.eu>w@1wt.eu>
>> To: "HTTP Working Group" < <ietf-http-wg@w3.org>ietf-http-wg@w3.org>
>> Sent: 26/11/2012 8:35:26 p.m.
>> Subject: Message length and caches
>>
>>> 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
>>
>>
>