jakarta-cactus-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gunnar Ole Skogen <Gunnar.Sko...@ergo.no>
Subject RE: setUserData ( multipart/form-data ) :=> low levelstuff
Date Thu, 21 Mar 2002 12:55:12 GMT
Vincent,
 That's right, I believe cos.jar has become somewhat of a standard for
reading multipart.

HttpClient: If we can HttpClient.addMultipartParameters and afterwards
setUserData(HttpClient.getMultipartBuffer()) nothing or very very little (
perhaps hide this inside the Cactus WebRequest .. ) or even better, not to
use the userData stream but have a stream for the multipart buffer..... 

Gunnar

-----Original Message-----
From: Vincent Massol [mailto:vmassol@octo.com]
Sent: 19. mars 2002 10:46
To: 'Cactus Users List'
Subject: RE: setUserData ( multipart/form-data ) :=> low levelstuff


Gunnar,

Thanks for the explanation. If I understand correctly, there are 2 APIs
to provide to help handle "multipart/form-data" :

* one for sending the request (this could and should be provided IMO by
HttpClient). Note: I've just sent an email to commons-dev to ask if
HttpClient supports multipart/form-data.

* one for easy reading of the request (on the server side). This is what
cos.jar is providing.

As I said, I don't believe we should implement it in Cactus. However, it
must be easy for users to test multipart/form-data. Thus, if HttpClient
supports multipart and if users use cos.jar, it should work fine, right
?

Thanks
-Vincent

> -----Original Message-----
> From: Gunnar Ole Skogen [mailto:Gunnar.Skogen@ergo.no]
> Sent: 18 March 2002 12:04
> To: Cactus Users List
> Subject: RE: setUserData ( multipart/form-data ) :=> low levelstuff
> 
> Vincent,
> 
> Last first: "multipart/form-data" :
> My knowledge of this is not complete, but if you have a FORM with the
> usual
> INPUT elements and one or more of these are of type="file" ( which is
when
> the client wishes to upload a file to the server ), the
> "multipart/form-data" is what you need. The Request the server
receives
> from
> this will contain the the file(s) for upload as well as all the other
FORM
> elements ( which otherwise would be retrieved using
request.getParameter()
> ).
> I use this in an application where the user submits FORM data with
> shipping
> freight data + also has the possiblity of submitting one or more files
as
> attachments along with other the data as in a e-mail.
> The intent is to be able to send form data mixed with ex. file(s).
Done by
> using a declared delimiter between elements in a buffer.
> The http://www.servlets.com/cos/index.html site contains a library,
> cos.jar,
> for reading multipart form data from a request into a multipart object
> with
> getParameter() and getFile() methods.
> 
> Had a brief look at Jakarta Commons HttpClient: uncertain, maybe
"chunked"
> transfer etc.. When time permits I will look into it more closely.
> However,
> I see no html parsing going on here.
> 
> HttpUnit : does support multipart, so the symetry if poss.. : when
time
> allows I will see if HttpUnit's stuff could be used to build the
multipart
> request and thereafter extract it as a buffer for setUserData()....
> bypassing any grave issues..
> 
> 
> Binary files: can be sent in a multipart
> 
> Thanks for your answer
> 
> Gunnar
> 
> 
> -----Original Message-----
> From: Vincent Massol [mailto:vmassol@octo.com]
> Sent: 15. mars 2002 20:06
> To: 'Cactus Users List'
> Subject: RE: setUserData ( multipart/form-data ) :=> low levelstuff
> 
> 
> Gunnar,
> 
> Thanks for your proposition. This is indeed interesting. I remember
that
> when I introduced the HttpUnit WebReponse integration I also thought
> about using the HttpUnit's features to send HTTP requests. However, I
> think there will be issues. But I haven't looked in details. Maybe
they
> can be overcome ?
> 
> WRT your proposition about a higher level API to send HTML, I think it
> is interesting although I'd like to see some more details. Also, does
it
> work for sending XML in the same way ? What about binary files ? Or is
> geared specifically for multipart/form-data ?
> 
> Also, do you know if Jakarta Commons HttpClient already provides this
> feature. If not, wouldn't it be best to implement it in that project
> (especially as Cactus is already using HttpClient) ? I'd love not to
> have to maintain this feature as part of Cactus as it is not really
> related to Cactus's core business. I'm quite sure there would be
> interest for it on Jakarta-Commons. If you're interested, can you post
a
> message on Commons-dev ?
> 
> I don't much about multipart/form-data. What is the intent ? When is
it
> used  over simple form data (POST) ? I have never had the need to use
it
> in all my web projects which is probably why I am so ignorant of it !
> :-)
> 
> Thanks
> -Vincent
> 
> > -----Original Message-----
> > From: Gunnar Ole Skogen [mailto:Gunnar.Skogen@ergo.no]
> > Sent: 28 February 2002 07:29
> > To: cactus-user@jakarta.apache.org
> > Subject: setUserData ( multipart/form-data ) :=> low levelstuff
> >
> > Hi,
> >
> > Proposal for new feature:
> >
> > Using setUserData to sent a multipart/form ( or other) means one has
> to do
> > what a browser does when sending a request from a form with
> ContentType =
> > multipart/form-data. I did this low level stuff ( inserting
parameter
> > element, boundaries, reading files into the buffer etc) and it
works.
> >
> > What would be time saving is to be able to simply input the html
code
> in
> > the
> > request in the future.
> > Using HttpUnit's request class as one can use it's response class
> would
> > make
> > things symetric ( have not checked if the above is possible with
> HttpUnit
> > )
> > There probably are some 3rd party libs for transforming html into a
> > request-object ?
> >
> > If you are interested and this,  in that case, needs to be
implemented
> in
> > Cactus itself, I can send you the code I use for inserting
> > multipart/form-data into setUserData .
> >
> > -Gunnar Skogen
> >
> > --
> > To unsubscribe, e-mail:   <mailto:cactus-user-
> > unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail: <mailto:cactus-user-
> > help@jakarta.apache.org>
> >
> 
> 
> 
> 
> --
> To unsubscribe, e-mail:
> <mailto:cactus-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
> <mailto:cactus-user-help@jakarta.apache.org>
> 
> --
> To unsubscribe, e-mail:   <mailto:cactus-user-
> unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:cactus-user-
> help@jakarta.apache.org>
> 




--
To unsubscribe, e-mail:
<mailto:cactus-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail:
<mailto:cactus-user-help@jakarta.apache.org>

--
To unsubscribe, e-mail:   <mailto:cactus-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:cactus-user-help@jakarta.apache.org>


Mime
View raw message