- From: Willy Tarreau <w@1wt.eu>
- Date: Wed, 11 May 2011 00:29:04 +0200
- To: Brian Pane <brianp@brianp.net>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
On Tue, May 10, 2011 at 03:13:06PM -0700, Brian Pane wrote: > I can imagine variants of Willie's use case that happen even in the > absence of chunking: an origin server receiving a large file upload > might attempt to stream back a response "10% complete ... 20% ..." > incrementally. yes that's one valid point. > Thus I think the general issue is: Should a > proxy be allowed to (or prevented from, or perhaps even required > to) stream a request though toward the origin server before it > receives the entirety of the request? Well, we can't prevent a proxy from doing so because we can't require it to buffer all the response. We can't make it mandatory to do so either because some proxies will need to analyse everything before letting the request pass (think webmails + anti-virii). So we must only let them do what they feel right for what they do. In fact there is a large spectrum of possibilities depending on the usage. > I think the "allowed to" option is the most pragmatic approach. Indeed. > There are proxies that have good reasons for buffering the entire > request body (ease of implementation, scanning of POST payload > for malicous input), and there are proxies that have good reasons > for not buffering the request body (minimization of memory usage, > denial-of-service avoidance). It seems prudent to let each > implementor decide what tradeoffs are best for their implementation. Exactly. My concern is not with proxies, as I think they all have valid reasons to act as they do (and difficulty to implement support for either method is a valid reason too in my opinion). My concern is with people spending time inventing protocols that will not be able to work on top of 100%-compliant proxies. There surely is something that can be done so that those people don't waste their (nor their users') time implementing and deploying something which will break once widely deployed. And since it's not the first time I read suggestions of such a way of turning HTTP into a full duplex link, I think there is room left for ambiguity. It has even been evocated on the hybi ML several months ago. And a decade ago I used to abuse squid's interactive handling of POST to telnet home from customers' so I can't blame implementors for trying to use the protocol that way :-) Regards, Willy
Received on Tuesday, 10 May 2011 22:29:30 UTC