- 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>
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. Yes. 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 process. - 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. Regards Henrik
Received on Tuesday, 8 April 2008 09:10:27 UTC