Thanks for the pointer. I guess my big issue with this code as well is the use of static fields, particularly for the boundary. Since the boundary is supposed to be variable for each multipart message this implementation would not work work a multi threaded application like we have. I would be interested in taking this code as a starting point and I'll submit my modified version although it will be fairly different due to the conversion of much of the static code.
-Eric
Kalnichevski, Oleg wrote:
------------------------------------------------------------------------
Subject: RE: multipart/form-data Boundary issues From: "Kalnichevski, Oleg" <[EMAIL PROTECTED]> Date: Tue, 29 Jun 2004 17:31:03 +0100 To: "Commons HttpClient Project" <[EMAIL PROTECTED]>
To: "Commons HttpClient Project" <[EMAIL PROTECTED]>
Eric
There's a project currently hosted in the commons sandbox aimed at factoring multipart code out of HttpClient and eventually merging it with commons [codec].
http://cvs.apache.org/viewcvs.cgi/jakarta-commons-sandbox/codec-multipart/
Feel free to take it as a starting point and consider contibuting your code back to the project
Oleg
-----Original Message----- From: Eric Dalquist [mailto:[EMAIL PROTECTED] Sent: Tue 6/29/2004 18:02 To: Commons HttpClient Project Cc: Subject: Re: multipart/form-data Boundary issues
Ortwin Glück wrote:
Eric Dalquist wrote:
I've been looking through the code dealing with multipart form uploads and have a few questions. First off, what happens if the text that someone is uploading contains the boundary text since it is hard coded in this implementation?Eric,
Actually a hard coded boundary string is bad practice. It should be randomly generated each time. Feel free to file a bug report.
If your text is likely to contain the boundary string, you should use some Content-Transfer-Encoding like Base64 or quoted-printable or something. Please refer to the respective MIME specification (RFC-2045, RFC-2046, RFC-2047 and RFC-2049).
Also I'm actually looking at the code to reconstruct a multipart/form-data message body from a set of files and named parameters. I don't actually want to send a request, just create the body and write it to a stream.
That should pose no problem.
My only issue is that I need to be able to set the boundary string from my code.Why would one want to set the boundary string explicitly? A MIME compliant server does not care about the actual boundary string value.
I have a special case for this one. I'm working no a bug fix for some portal software. The software currently reads the HttpRequest and parses out any submitted file data to temp files stored on the disk as they are being uploaded to cut down on memory requirements. The problem is at a later point in the request chain a wrapped instance of the same HttpRequest is passed to a JSR-168 portlet. To be standards compliant the portlet should just read the submitted file data from the input stream of the request but since the input stream has already been read and the files stored this is not possible, Our solution is to override the method that returns the ServletInputStream to the body of the request and re-construct the submitted body on the fly from the temp files and stored parameters. The boundary that was used by the submitting client is stored in the content type field and is easy to retrieve. Re-using this boundary would ensure that it is unique for the data since it was already used once and it would be one less method we have to override.
I actually decided to make our own implementation of the multipart creation classes. Looking through the httpclient code it would be a very large change since the code is based very largely around the use of static fields. This makes the code unusable in a multi-threaded environment.
If you would like I can post the final product of my code in a day or two when it is complete.
-Eric Dalquist
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
------------------------------------------------------------------------
***************************************************************************************************
The information in this email is confidential and may be legally privileged. Access to this email by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system.
***************************************************************************************************
------------------------------------------------------------------------
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
