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 Fri, 16 Jan 2004 15:37:56 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-16 15:37 -------
The optimization for small buffers is just that, an optimization. Chunking can
be quite wasteful for small payloads, both in terms of total transfered bytes
and the logic to encode/decode the chunk. As for the coupling to HttpConnection
and HttpState, I was just trying to be consistent with the current api.
Practically all write methods in HttpMethodBase take HttpConnection and
HttpState as parameters.  That's not strictly necessary. In this particular
case, we could store those values in StreamedPostMethod and then
BufferedChunkedOutputStream wouldn't ever get to see those.

I think the real architectural issue here may be that HttpClient assumes all
headers must be available before at least some processing is performed on the
body. That assumption is not true in this case. There are other cases where that
assumption makes using HttpClient difficult. For example consider a case where
you conditionally compress the payload or not based on size. The content type
can't be set until you've decided to go one way or another and that will depend
on processing the body.

I tried to point out the coupling in the initial comment because I agree with
you: it is not elegant. I'm not sure there is an elegant solution here.
Honestly, I dislike the reverse coupling (StreamedPostMethod knowing about
BufferedChunkedOutputStream) even more. In good servlet implementations (e.g.
Tomcat 5.x, Weblogic) the stream layer is totally transparent. What a servlet
does is not all that different than what HttpClient needs to do. Maybe the
Tomcat architecture would be a good starting point for the 3.0, or at least
something to keep in mind.

BTW, going back to the optimization: some servlet containers do the same.
Weblogic does. Tomcat does not.

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