hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 26070] - [RFE] Allow streaming of POST methods via chunked transfer encoding.
Date Thu, 22 Jan 2004 18:27:33 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26070>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26070

[RFE] Allow streaming of POST methods via chunked transfer encoding.





------- Additional Comments From mohammad.rezaei@gs.com  2004-01-22 18:27 -------
hah! It takes more than words to discourage me :->
I've actually been a little busy, but kept this in the back of my mind. The way
I see it, there are 3 ways to proceed (in order of difficulty, reverse order of
"goodness"):
1) Forget about refactoring the BufferedChunkedOutputStream and make it an inner
class of StreamedPostMethod. This is actually how I wrote the code originally.
2) Take out the first chunk optimization. This makes BufferedChunkedOutputStream
a simple replacement for the current implementation. See below.
3) Teach HttpMethodBase how to deal with delaying headers. This may not be too
bad in time for 2.1 (are we calling that 3.0 now?). I haven't had time to take a
close look.

The reason I'm hesitant about 2 is that HttpClient is used by a wide range of
people, most of whom don't care about large POST payloads. The nice thing about
first chunk optimization is that it transparently uses a more widely available
Content-Length header. There are alot of broken proxies/load
balancers/firewalls/webservers out there. It would be nice for a general purpose
library to use the more common form when it can. There is nothing preventing
people from doing their own buffering; this is just a convenience. FYI, for my
purposes, option 2 will be just fine.

Thanks
Moh

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org


Mime
View raw message