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=30834>. 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=30834 MultipartPost string part without defaults [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |INVALID ------- Additional Comments From [EMAIL PROTECTED] 2004-08-25 18:56 ------- Tom, With all due respect, I still think that HttpClient is not at fault here. Feel free to examine the source code: http://jakarta.apache.org/commons/httpclient/xref/org/apache/commons/httpclient/methods/multipart/Part.html#178 Both the content type and transfer encoding headers are not generated when set to null. StringPart part = new StringPart("name", "value"); part.setContentType(null); part.setTransferEncoding(null); Can it be that you use an empty string instead? StringPart part = new StringPart("name", "value"); part.setContentType(""); // wrong part.setTransferEncoding(""); // wrong BTW, for your information IE actually violates the MIME specification by assuming that the default transfer encoding is 8bit whereas it is supposed to be 7bit. This is the reason why HttpClient includes a transfer encoding header per default Hope this helps Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
