hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: multipart/form-data Boundary issues
Date Tue, 29 Jun 2004 19:44:41 GMT
Eric,
Mark Diggory has started the refactoring of the multipart code but does
not seem to not have completed it. You should probably consult with him 
regarding the direction of further efforts and API changes. Post a
message to the commons development list (commons-dev@jakarta.apache.org)
stating [codec-multipart] in the subject line

I have been long planing to contribute my share to the refactoring work
of [codec-multipart] but I am currently completely absorbed with writing
the API documentation for HttpClient 3.0 (well, thinking about
writing... forcing myself to think about writing... [sigh])

Oleg


On Tue, 2004-06-29 at 19:42, Eric Dalquist wrote:
> 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" <oleg.kalnichevski@bearingpoint.com>
> > Date:
> > Tue, 29 Jun 2004 17:31:03 +0100
> > To:
> > "Commons HttpClient Project" <commons-httpclient-dev@jakarta.apache.org>
> >
> > To:
> > "Commons HttpClient Project" <commons-httpclient-dev@jakarta.apache.org>
> >
> >
> >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:edalquist@unicon.net]
> >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: commons-httpclient-dev-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
> >
> >
> >
> >
> >  
> >
> >------------------------------------------------------------------------
> >
> >***************************************************************************************************
> >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: commons-httpclient-dev-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org


Mime
View raw message