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

Re: Upload negotiation

From: Henrik Nordstrom <henrik@henriknordstrom.net>
Date: Tue, 08 Apr 2008 11:07:56 +0200
To: Adrien de Croy <adrien@qbik.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <1207645676.31831.33.camel@HenrikLaptop>

tis 2008-04-08 klockan 13:44 +1200 skrev Adrien de Croy:

> Seems to me that getting around message - length / connection 
> maintaining issues by using chunking so you can send a premature final 
> chunk instead of terminating the connection is asking for a whole lot of 
> pain.  It's an ugly hack.

I disagree.

> For starters, there's then no way to tell the recipient that the 
> completion was an abortive one.

It's the recipient who asked for it to be aborted by sending an error
instead of 100 continue.

> If there are several processes in an 
> intermediary or end server that the data goes through before getting to 
> the module that caused the client to abort, then you've got all manner 
> of things may happen to that data which appears complete.

> That's where it would have been useful to support notifying an abortive 
> end ( e.g. previously discussed negative 1 chunk length ) to a 
> transfer.  Abort without closing.

Then propose a chunk extension for that purpose.. I.e. something like

0; aborted

> All in all I think using chunked uploads is bad for many reasons, apart 
> from the fact that it's probably poorly supported even in existing 
> HTTP/1.1 infrastructure.  Using it so you can stop sending a body is 
> even worse.

I obviously don't share that opinion.

> As I said, it's possible ("a client can") to have a connection followed 
> by initiation of a large transfer without any notification of acceptance 
> by the thing that will have to swallow the data or reject and disconnect.


Same is also true for request headers, or URL lengths..

> If you want proof of the problem, try uploading a 100MB file across a 
> slow WAN through a proxy that requires auth to a poorly-connected server 
> that requires auth (a fairly common scenario actually).  Basically 
> impossible because depending on the auth method, that 100MB may have to 
> be sent up to 6 times.

Well, ignoring connection oriented auth the client SHOULD either use
chunked encoding or close the connection, aborting the request when
seeing the challenge. Clients SHOULD NOT send the whole body after
receiving an error. This is already spelled out verbatim in the specs
under "Monitoring Connections for Error Status Messages".

This got screwed up the day someone decided that connection oriented
authentication is a good thing in a message oriented protocol where each
message is supposed to be self-contained... I won't even comment on what
disaster that is to the process. The use of chunked encoding helps
avoiding some of the disaster thankfully.

> Try an analogy - e.g. a fertiliser delivery company.
> the HTTP way:
> * The truck turns up and starts dumping fertiliser in your driveway
> * you come out and scream at it.
> * it stops
> * you clean up
> * maybe it comes back and dumps some more fertiliser in your driveway 
> soon after

I see where you are coming, but you got the roles the wrong way around
for it to match HTTP. A more proper analogy would be a person trying to
place an order, or someone wanting to send a package at the post office.

Example based on the order. Note that there is a twist here in that if
you hand over the order form and there is a problem you can't get it
back and have to fill out a new copy.

- Person fills out his order form and goes to the counter where the
order is supposed to be placed.
- If the customer is polite he asks if he may place the order before
handing over the order form, or if in a hurry he hands over the order
form immediately hoping for the best.
- Gets told that he need to have some proof of his customer number in
order to place the order. 
- Goes away to fetch his customer card proving his identity in the
- Back at the counter again repeating the process

Or another version where everything is in order

- Person fills out his order form and goes to the counter where the
order is supposed to be placed.
- The customer is polite and asks if he may place the order before
handing over the order form
- The processing agent is currently busy processing another order and
doesn't answer immediately.
- The person hands over the order form when the processing agent says
it's ready, or if he suspects the processing agent or the communication
with it is oldfashioned and outdated and doesn't indicate readiness.

Received on Tuesday, 8 April 2008 09:10:27 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:45 UTC