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=20744>. 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=20744 HTTPClient MultiPartPostMethod inconsistent behaviour compared to standard form upload ------- Additional Comments From [EMAIL PROTECTED] 2003-06-16 09:33 ------- Odi, not a problem I did not feel offended :-). I completely agree with you, as it is not up to me to fiddle around with multipart headers. Servers and clients should follow the defined RFCs, and as users of components we ought to trust it. Odi, Oleg Again, I fiddled with it, because performing the action via browsers did work, and performing the action with httpclient did not. Some hacking on the headers revealed to me that if I "simulated" the browsers headings it worked, while leaving the headers as it should be (the HTTPCLient) it didn't. By the way for those interested : I did a simulation on 3 browsers (MS-IExplorer 5.5 SP2, Netscape 4.79 and Mozilla 1.2.1) and all gave the same multiparts as described in the original bug report (POST submit via HTTP form). I found RFC2388 which indicates that "Content-transfer-encoding" is not apparently mandatory if the encoding matches the original transfer-encoding header. Apparently header "Content-type" is mandatory, but the browsers do not submit them, only for the uploaded file. Oleg, I use struts v1.0.2 Which is up to now the "stable version". No intentions for migration at this moment. Maybe when 1.1 becomes stable. We have a "production" system, and betas are considered as "not done" by management. Maybe we should ensure that the guys of struts or the fileupload check this out. regards dirkp --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
