Re: Message length and caches

(or am I crazy? :) )
-=R


On Mon, Nov 26, 2012 at 3:13 PM, Roberto Peon <grmocg@gmail.com> wrote:

> 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
>>>
>>>
>>
>