You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by Alexander Sack <as...@c1-fse.de> on 2005/05/20 11:38:34 UTC
[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
--
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
Re: [FileUpload/HTTPClient] (re)encode already consumed multipart
request
Posted by Alexander Sack <as...@c1-fse.de>.
Martin Cooper wrote:
>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?
>
>
>
Simple answer, in order to determine what to do (and if we want to proxy
this request) we need to inspect the parameters that come in, so parsing
the stream is not optional for us.
Thanks,
--
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
RE: [FileUpload/HTTPClient] (re)encode already consumed multipart request
Posted by James Sangster <ja...@newswire.ca>.
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.
Thanks,
james
-----Original Message-----
From: Martin Cooper [mailto:mfncooper@gmail.com]
Sent: Friday, May 20, 2005 3:31 PM
To: Jakarta Commons Users List
Subject: Re: [FileUpload/HTTPClient] (re)encode already consumed multipart
request
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 <as...@c1-fse.de> 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: 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
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [FileUpload/HTTPClient] (re)encode already consumed multipart request
Posted by Martin Cooper <mf...@gmail.com>.
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 <as...@c1-fse.de> 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: 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
Re: [FileUpload/HTTPClient] (re)encode already consumed multipart request
Posted by Oleg Kalnichevski <ol...@apache.org>.
Alexander,
I think the code should be in a reasonably usable state, but you should
probably check with Mark Diggory <mdiggory at apache.org> who is the
primary contributor on this project.
At some point I'll have to get involved as well. HttpClient is
currently undergoing a complete API redesign and code rewrite. We
certainly will no longer have multipart related code in HttpClient as of
next major release (4.0, that is). Ideally I would like to see
codec-multipart merged into commons-codec proper
Oleg
On Fri, May 20, 2005 at 02:26:00PM +0200, Alexander Sack wrote:
> Oleg Kalnichevski wrote:
>
> >Alexander,
> >
> >The codec-multipart project in commons sandbox aims at factoring
> >multipart related code out of commons-httpclient. Rather unfortunately
> >the project has been inactive for quite a while
> >
> >http://svn.apache.org/repos/asf/jakarta/commons/sandbox/codec-multipart/trunk/
> >
> >Oleg
> >
> >
> Thanks Oleg for the info,
>
> you know if the project is in a usable state? If it is not completely
> broken, I could help to improve it a bit.
>
> --
> 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
Re: [FileUpload/HTTPClient] (re)encode already consumed multipart
request
Posted by Alexander Sack <as...@c1-fse.de>.
Oleg Kalnichevski wrote:
>Alexander,
>
>The codec-multipart project in commons sandbox aims at factoring
>multipart related code out of commons-httpclient. Rather unfortunately
>the project has been inactive for quite a while
>
>http://svn.apache.org/repos/asf/jakarta/commons/sandbox/codec-multipart/trunk/
>
>Oleg
>
>
Thanks Oleg for the info,
you know if the project is in a usable state? If it is not completely
broken, I could help to improve it a bit.
--
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
Re: [FileUpload/HTTPClient] (re)encode already consumed multipart request
Posted by Oleg Kalnichevski <ol...@apache.org>.
Alexander,
The codec-multipart project in commons sandbox aims at factoring
multipart related code out of commons-httpclient. Rather unfortunately
the project has been inactive for quite a while
http://svn.apache.org/repos/asf/jakarta/commons/sandbox/codec-multipart/trunk/
Oleg
On Fri, May 20, 2005 at 11:38:34AM +0200, 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: 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
Re: [FileUpload/HTTPClient] (re)encode already consumed multipart
request
Posted by Alexander Sack <as...@c1-fse.de>.
James Sangster wrote:
>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).
>
>
Yes, that is almost exactly the same thing we are trying to do.
Nevertheless, we need to be able to inspect the uploaded items and
decide on that basis to which backend to forward it or if we want to
forward it at all.
Further, we are trying to do the same kind of forward within the servlet
container itself (e.g. forward/include from a webapp). In this case, we
cannot use any HTTP specific code ... we need just the multipart stream,
so the forward servlet/jsp can consume it as if it has been invoked
directly.
Anyway, I can't tell how to accomplish this in an elegant fashion for
now. Any ideas are welcome.
>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.
>
>
If I found a viable solution I will post it here.
Thanks,
--
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
RE: [FileUpload/HTTPClient] (re)encode already consumed multipart request
Posted by James Sangster <ja...@newswire.ca>.
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]
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
--
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