--- Begin Message ---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]<<winmail.dat>>
--- End Message ---
*************************************************************************************************** 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]
