Subject: Message length and caches

From: Willy Tarreau <[email-masked]>
Date: Mon, 26 Nov 2012 08:35:26 +0100

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

---

From: Roberto Peon <[email-masked]>
Date: Sun, 25 Nov 2012 23:52:02 -0800

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

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Mon, 26 Nov 2012 08:09:55 +0000

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

---

From: Roberto Peon <[email-masked]>
Date: Mon, 26 Nov 2012 02:23:30 -0800

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 <[email-masked]> wrote:

> Since that intermediary can't tell the difference between an abortive and
> normal close, it will send a 0 chunk on close.
>
> So I agree with Roberto about use of TCP close as a protocol signal, but
> we're stuck with it.
>
> Adrien
>
>
>

---

From: Amos Jeffries <[email-masked]>
Date: Tue, 27 Nov 2012 00:26:16 +1300

On 26/11/2012 11:23 p.m., Roberto Peon wrote:
> 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.
> close, or it could take the form (if we extend the spec) of a new 
> header of some kind.

A header is kind of a non-starter unless it is a trailer or chunk 
indicator of some kind. Abortions can happen on responses too large to 
buffer - very likely to in fact.

Amos

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Mon, 26 Nov 2012 22:36:45 +0000

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" <[email-masked]>
To: "Adrien W. de Croy" <[email-masked]>
Cc: "Willy Tarreau" <[email-masked]>;"HTTP Working Group" 
<[email-masked]>
Sent: 26/11/2012 11:23:30 p.m.
Subject: Re: Message length and caches
>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.
> 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).
>

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 26 Nov 2012 15:03:25 -0800

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
> 
> Cc: "Willy Tarreau" <[email-masked]>;"HTTP Working Group" <[email-masked]>
>> 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
>> 
>> 
>> 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 I agree with Roberto about use of TCP close as a protocol signal, but we're stuck with it.
>> 
>> Adrien
>> 
>> 
>>

---

From: Roberto Peon <[email-masked]>
Date: Mon, 26 Nov 2012 15:13:08 -0800

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 <[email-masked]> wrote:

> 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.
>
> On Mon, Nov 26, 2012 at 12:09 AM, Adrien W. de Croy < <[email-masked]>
> [email-masked]> wrote:
>
>> Hi Willy
>>
>> From: "Willy Tarreau" < <[email-masked]>[email-masked]>
>> To: "HTTP Working Group" < <[email-masked]>[email-masked]>

---

From: Roberto Peon <[email-masked]>
Date: Mon, 26 Nov 2012 15:13:45 -0800

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

On Mon, Nov 26, 2012 at 3:13 PM, Roberto Peon <[email-masked]> wrote:

> On Mon, Nov 26, 2012 at 3:03 PM, Roy T. Fielding <[email-masked]>wrote:
>
>> the response as if it was uncacheable and attempt to convey to the client
>> that the originator of the response framed with connection close.

---

From: David Morris <[email-masked]>
Date: Mon, 26 Nov 2012 15:45:33 -0800 (PST)

On Mon, 26 Nov 2012, 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.
> 
> 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?

In case where the origin server provides a response claimed to be 1.1 w/o
a content length or chunked encoding, that is an invalid HTTP/1.1 
response, is it not? That error needs to be signaled to the client so I
think the proper handling is to close the chunked response stream W/O 
sending the 0 chunk .. yes there is a penalty here of closing the
connection, but this is an error and I believe it MUST be signaled as
effectively as possible. If we really had effective trailers, that would
be a better handling alternative.

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Tue, 27 Nov 2012 00:14:45 +0000

------ Original Message ------
From: "David Morris" <[email-masked]>
>response, is it not?
nope, it should indicate Connection: close though

>That error needs to be signaled to the client so I

I'd prefer extending the chunk schema to allow for some sort of status 
rather than using a trailer which is an HTTP header relating to the 
entity rather than transfer thereof

but this is moot? Unless we are going to target a 1.2, we won't be 
extending chunking in the same way, and the new chunk design should 
have room for signalling all manner of issues.

and should probably be the only transfer mechanism.

instead of a 0 chunk, we could adopt an IP header approach - more 
fragments or not.  That would allow transfer of an entity in a single 
chunk without requiring an additional PDU to close the stream.

Adrien