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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
