André Warnier wrote:
Kyle Brantley wrote:
...
My point, is that it is entirely possible for a browser to POST data
to a resource without sending it as multipart/form-data or
application/x-www-form-urlencoded.
Hey! that is cheating. You never mentioned Javascript before.
;-)
But true. I wasn't thinking of XMLHttpRequest (which is becoming
entirely misnamed these days). You /can/ POST any body which strikes
your fancy.
And you are also right when you mention that assembling a real
multipart/form-data body may be a p. in the a.
Which is really the only reason that matters as to why I wanted to do
it. I don't want to encode/decode to send to the server, and then do the
same to send to the client. It's a very simple solution.
The real question however is whether you /should/.
Definitely. Granted on every count.
My point (awaiting a more expert opinion still), is that I believe
that the way the servlet spec is written, you may very well get away
with it under one servlet container, but not under another.
Now whether this is a concern in your particular circumstances, is for
you to know.
*nod* Probably will only ever be using tomcat. Unless someone suggests
something else, but I don't think that would be the case... /here/. :)
As an aside : in your case, there is also not much stopping you from
sending your XML body in a way guaranteed to work in all cases.
You could send it as
name=........ all your XML, properly URL-encoded ..........
Then it would work also with getParameters().
And you know, I really debated that - but for absolutely no reason at
all, I really wanted to see if I could accomplish it without. That, and
I wasn't sure if I would need to tack on extra encoding - the XML in
question has quite a few element attributes, all with their own
var=whatever pairs. I wasn't positive how getParameter*() would parse
that, and if I would/wouldn't need to add extra encoding. As you laid
out right there, I would need to URL encode the data, and the reality is
I just don't care that much (when presented with another solution that
works with arguably less effort). The client is straight javascript, and
while I'm not the one doing the client ("not my problem"), it would just
be added effort for little to no gain.
Unless it is really long of course; I would not recommend this with a
file. But in that case, there is this :
http://commons.apache.org/fileupload/using.html
which also allows you to handle multipart/form-data containing blobs
and simple form parameters, together in one POST.
(Mentioning it because I have often found that what is at the
beginning a simple case where "all we need to upload, ever, is a
single blob", turns out in the end to be "..but we'd also like to send
some additional meta-data describing the blop").
Right. I doubt we'll ever have a need for that, but it would also be an
option.
I am curious just how the expert opinion turns out, though.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
