Oh.. so I can stuff data in the body, even if the message is a PUT
message?  Not sure how to do that with curl without sending a bogus
file along for the ride.. but if that's what you are saying then I
guess that'd be acceptable.  With the exception of some GIF/PNG/JPEG
images now and again, the primary data will be XML files, some large
some small.  The primary sender will be a Javascript application
making the webservice calls directly.

Alan

On Feb 16, 3:18 pm, Tim Perrett <[email protected]> wrote:
> I can understand why he wants to use PUT - its more resource
> orientated.
>
> I think we should stop talking about file uploads in the traditional
> sense, as the current lift design is "doing the right thing" for
> normal form based uploads.. However, lets talk about passing large
> entity bodies with web services and what *exactly* you are transfering
> and why.
>
> When im passing large bodies around in my web services, the binary
> content is usually passed as element content (base64 encoded) inside
> my XML body message  as I might be passing some other meta-data such
> as name or whatever (in the case of an image). For example, my request
> body might look like:
>
> <image>
>   <name>some image</name>
>   <data>....</data>
> </image>
>
> Where <data> include a base64 encoded image or whatever. This is of
> course an example, but you see how it can work?
>
> Thanks
>
> Tim
>
> On Feb 16, 11:10 pm, David Pollak <[email protected]>
> wrote:
>
> > On Mon, Feb 16, 2009 at 2:58 PM, Alan M <[email protected]> wrote:
>
> > > OK I think I follow up to a point.. so Lift needs to know that it's
> > > multipart to work correctly with a put, and it doesn't.  That much I
> > > get, seems like Put is just broken.
>
> > We are relying on the Apache multipart library to handle multipart uploads.
> >  The library conforms to RFC 1867 which only defines multipart file uploads
> > for POSTs (not PUT, etc.)
>
> >http://www.ietf.org/rfc/rfc1867.txt
>
> > Are you writing your Lift app to a particular spec and if so, can you point
> > us to that spec?
>
> > Thanks,
>
> > David
>
> > What I don't understand is that
>
> > > last bit though..  When you say:
> > > > you can pass your entity body and just access the
> > > > req.body property
> > > Where could you do that?  I don't build the requests myself, so would
> > > I have to modify the Lift code to do this?  Is there an extension
> > > point to make that happen?  (like set request builder here or
> > > something and a class I can extend)
>
> > > Alan
> > > On Feb 16, 2:25 pm, Tim Perrett <[email protected]> wrote:
> > > > Would it not be because of:
>
> > > > ServletFileUpload.isMultipartContent(request) // Req.scala line 79
>
> > > > If you then reference the commons lib, the source of that method looks
> > > > like:
>
> > > >     public static final boolean isMultipartContent(
> > > >             HttpServletRequest request) {
> > > >         if (!"post".equals(request.getMethod().toLowerCase())) {
> > > >             return false;
> > > >         }
> > > >         String contentType = request.getContentType();
> > > >         if (contentType == null) {
> > > >             return false;
> > > >         }
> > > >         if (contentType.toLowerCase().startsWith(MULTIPART)) {
> > > >             return true;
> > > >         }
> > > >         return false;
> > > >     }
>
> > > > As DPP says, it looks as though you will *need* to make it a POST
> > > > request, and also set the content type to multi-part.
>
> > > > Alternatively, if, like me, you dont want to use overloaded post as
> > > > its not very ROA, you can pass your entity body and just access the
> > > > req.body property... you wouldnt get any of the useful lift helpers,
> > > > but of course it depends on your use case :-)
>
> > > > Cheers
>
> > > > Tim
>
> > > > On Feb 16, 10:05 pm, David Pollak <[email protected]>
> > > > wrote:
>
> > > > > On Mon, Feb 16, 2009 at 1:53 PM, Alan M <[email protected]>
> > > wrote:
>
> > > > > > I'm still working away on my web service project (mentioned many
> > > > > > months ago when I first lobbied to get Scala used) and we rely
> > > heavily
> > > > > > on Put requests to create new resources.  My first attempt involving
> > > > > > Put and I've been stumped.
>
> > > > > > I've been able to run the server (using mvn/jetty) and my webapp 
> > > > > > gets
> > > > > > a PUT request (says so in the log produced by Jetty) and it does
> > > > > > everything it's supposed to in my code, except it never gets the put
> > > > > > file.  I used curl to make the call and it shows the bar saying it's
> > > > > > uploading the file and finishing.  In the server code, the Reqs body
> > > > > > is an Empty Box and it's uploadedFiles is an empty List.
>
> > > > > If you do a POST with the same data, does it work correctly
> > > (uploadedFiles
> > > > > gets populated)?
>
> > > > > > So my question is, where do I get that data from?  or is there
> > > > > > something else I need to do to turn that feature on? (enable file
> > > > > > upload or something?)
>
> > > > > > Alan
>
> > > > > > P.S. Something that might be relevant, since it's a webservice I'm
> > > > > > using the stateless dispatcher.. does that effect how/when the
> > > > > > paramCalculator works and therefore messes this up somehow?
>
> > > > > --
> > > > > Lift, the simply functional web frameworkhttp://liftweb.net
> > > > > Beginning Scalahttp://www.apress.com/book/view/1430219890
> > > > > Follow me:http://twitter.com/dpp
> > > > > Git some:http://github.com/dpp
>
> > --
> > Lift, the simply functional web frameworkhttp://liftweb.net
> > Beginning Scalahttp://www.apress.com/book/view/1430219890
> > Follow me:http://twitter.com/dpp
> > Git some:http://github.com/dpp
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to