Re: Message length and caches

------ Original Message ------
From: "David Morris" <dwm@xpasc.com>
>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.
>>
>>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?
>>
>
>
>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?
>
nope, it should indicate Connection: close though

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


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
>

Received on Tuesday, 27 November 2012 00:15:15 UTC