Mailing-List: contact commons-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Users List" <commons-user@jakarta.apache.org>
Received-SPF: pass (hermes.apache.org: local policy)
Reply-To: <james.sangster@newswire.ca>
From: "James Sangster" <james.sangster@newswire.ca>
To: "'Jakarta Commons Users List'" <commons-user@jakarta.apache.org>
Subject: RE: [FileUpload/HTTPClient] (re)encode already consumed multipart
 request
Date: Fri, 20 May 2005 10:50:15 -0400
Organization: CNW Group
Message-ID: <000d01c55d4b$3ba979a0$60d6a8c0@newswire.ca>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Importance: Normal
In-Reply-To: <428DB01A.4060702@c1-fse.de>

Hi Alexander,

I'm curious as to whether I understand the request you made below and
whether it is very similar (or the same) as to what I had been hoping to =
do.

I have a servlet which receives an HTTP multipart POST from a client, =
then
forwards that same request on to the final destination server (basically =
the
project is a HTTP proxy, whereby the client sends me data, and I send it =
on
to a configurable end server).

At present time I use the FileUpload component to handle the request =
from
the client and save the file to disk, then I construct a multipart POST
using HttpClient to send the data onwards.   If it's possible to avoid
saving the file to disk, but rather have it stream from the client =
request
into my new multipart POST to the end server, that would be great, and
probably help out the performance substantially.

The performance now isn't so bad, but should I start getting into bigger
files (on the order of magnitude of MBs), then the performance will =
suffer.

Any feedback from yourself or others on how to accomplish this would be
greatly appreciated.  Aside from this one little struggle, I must say =
that
HttpClient and FileUpload have made the job much simpler.

Thanks,
james


-----Original Message-----
From: Alexander Sack [mailto:asac@c1-fse.de]=20
Sent: Friday, May 20, 2005 5:39 AM
To: commons-user@jakarta.apache.org
Subject: [FileUpload/HTTPClient] (re)encode already consumed multipart
request


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

--=20
Alexander Sack    +49 (40) 692 13 - 179    e-mail:  asac@c1-fse.de
Contelligent ... a smart CMS solution - http://www.contelligent.com
C:1 Financial Services GmbH  -  Dorotheenstr. 64  -   22301 Hamburg


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


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