W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2008

Re: Upload negotiation

From: Patrick McManus <mcmanus@ducksong.com>
Date: Tue, 08 Apr 2008 10:44:20 -0400
To: Henrik Nordstrom <hno@squid-cache.org>
Cc: Adrien de Croy <adrien@qbik.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <1207665860.16851.236.camel@tng>


On Tue, 2008-04-08 at 16:06 +0200, Henrik Nordstrom wrote:

> 
> > Could make a SHOULD level requirement that user agents sending chunked 
> > requests that choose to abort them SHOULD include a "0 ; aborted" chunk 
> > extension.
> 
> I would make propose it being a MAY for 1.1, SHOULD or even MUST for
> 1.2.

I think it is great for 1.2, but doesn't help at all for 1.1.. deployed
engines will just ignore the unknown extension and view the message as a
complete one.. the sender is better off terminating the connection
early, creating a malformed chunked message and thereby at least getting
its point across - which is what happens now. I've written and
interoperated with sofwtare that works that way.

And its a huge improvement over the HTTP/1.0 semantics which has no
chunking and no content-length.. why no content-length? Because
streaming is often really important, either out of concern for latency
or state (especially in an intermediary). At least in HTTP/1.1 responses
chunking can be reliably used.

FWIW, It seems pretty common nowadays for HTTP/1.1 servers to correctly
accept chunked requests. I don't mean to say it's a sure thing - but
more often than not the server gets it right. That's a change in the
last few years. I've never implemented with an auto-discover cache so I
don't have numbers (my products just used config switches for enabling
chunked requests) but I would be interested in seeing them..

streaming seems an equally important feature for client and server to
me.
Received on Tuesday, 8 April 2008 14:45:10 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:50:47 GMT