Re: multipart/form-data Boundary issues

[Eric Dalquist]

A quick design question. I'm looking to also fix the code so that the 
filename field gets added to the Content-Disposition. Would it make more 
sense for the Part interface to have some generic methods called 
getConentDispositionLine getContentTypeLine and 
getContentTransferEncodingLine? Then each part could modify the lines as 
nessesary, such as a FilePart adding the fileName field on to the 
Content-Disposition string. Each method could have it's default behavior 
defined in AbstractPart and the javadoc could define the design contract 
as such.

A class overriding getConentDispositionLine method should call 
super.getConentDispositionLine() and then append fields to the returned 
string as nessesary, returning the final result from the overridding method.

Let me know what you think. The other solution would be to put an 
instanceof check for a FilePart in MultipartFormDataProvider and call an 
extra method on FilePart to get the fileName and append it to the 
Content-Disposition.

-Eric Dalquist
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]