DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.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://issues.apache.org/bugzilla/show_bug.cgi?id=26070 [RFE] Allow streaming of POST methods via chunked transfer encoding. ------- Additional Comments From [EMAIL PROTECTED] 2004-04-29 06:59 ------- > The new constructors are good, but there is a problem with the ByteArrayRequestEntity(). > It will always result in an exception since it's calling this(null). My initial intention was to do away with ByteArrayRequestEntity(), but than I thought I should discuss it with you first. > - I have no problem making these classes immutable, but I'm not sure it's really required. What's the > motivation? Primarily in order to avoid throwing IllegalStateException. If parameterless constructors and setContent may leave entity request objects in a inconsistent state, why should they exist in the first place? > - I think we should wait until we move the Content-Type to add a StringRequestEntity. That way we can > handle the charset problems all at once. I had originally created a StringRequestEntity but left it out for > this reason. I have concerns that some JDKs may end up converting the entire String to an array of bytes prior to writing into the underlying output stream, which would result in unnecessary waste of memory. I may be a little too pessimistic here, though Mike, just take over those bits that you think make sense and incorporate them into your coming patch. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
