commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Sangster" <>
Subject RE: [FileUpload/HTTPClient] (re)encode already consumed multipart request
Date Fri, 20 May 2005 19:54:56 GMT
I should use the term "proxy" lightly...   I get them to send me only as
little as possible to talk to an end system, and I take care of the rest
(authentication by cookie, additional parameters that can be configured;
basically they pass me the dynamic information).  It allows the client to be
simplified to calling a particular function and only passing certain
parameters which I need to verify the presence of, and in doing so, I need
to parse the request stream.

I dug around in FilePart and associated classes, but I see the constructors
all require a File object; if there is stream based one that someone knows
about, please let me know.


-----Original Message-----
From: Martin Cooper [] 
Sent: Friday, May 20, 2005 3:31 PM
To: Jakarta Commons Users List
Subject: Re: [FileUpload/HTTPClient] (re)encode already consumed multipart

Stupid question, I'm sure, but if you need to forward the data, then why
decode the stream in the first place? Just pass on the raw data. This would
seem to be the case for James too - why would a proxy decode the stream in
the first place?

Martin Cooper

On 5/20/05, Alexander Sack <> wrote:
> Hi,
> I am wondering if there is an easy way to (re)encode a multipart form 
> request, so I can send the stream to a different HTTP server without 
> the need to care for pitfalls when constructing valid multipart 
> requests?
> It is important to me that I don't need to use a complete HTTP API for 
> that (like the high level interfaces of the commons httpclient 
> project) ... at best I could just produce the payload stream of a 
> multipart POST request.
> I looked into the httpclient api ... and found 
> org.apache.commons.httpclient.Part implementations provide a way to 
> stream themselves to an output stream. But how to build a complete, 
> valid multipart stream from that without using a full HTTPClient 
> capability?
> Maybe it is enough to stream all parts to an output stream one by one? 
> If not, what else is needed to properly encode a multipart request 
> that has already been consumed by the fileupload api, to a new, valid 
> multipart stream?
> Any tricks or hints are welcome. TIA!
> Cheers,
> Alexander
> --
> Alexander Sack    +49 (40) 692 13 - 179    e-mail:
> Contelligent ... a smart CMS solution -
> C:1 Financial Services GmbH  -  Dorotheenstr. 64  -   22301 Hamburg
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message