Hi,
I think we could easily wrap the correct status code in JSON+Textarea
as it is done here: http://turtle.dojotoolkit.org/~dante/upload.html
in a ServletFilter, so that the application developer does not have to
care for generating the correct HTML and the client library could use
something like dojo.io.iframe which will parse the JSON from the
Textarea instead, which leads to much lighter client side code.
The servlet filter would simply detect if it is a multipart post and
if it is and if the response is JSON wrap it in a textarea and reset
the status code to 200. The client side code could inspect the form
automatically and switch from XHR to IFrame transport automatically
when a file upload in part of the post.
regards,
Lars
On May 6, 2008, at 8:23 , Felix Meschberger wrote:
Hi,
Am Dienstag, den 06.05.2008, 06:10 +0200 schrieb David Nuescheler:
I am fine with this, too. If there is no objection I will change
that
value to trigger the IE-friendly (which it is ;-) ) mode to
"browser".
I don't see any reason to include it as a mode. As a workaround,
sure,
but that should be very specific to the User-Agent field and not
require
special programming by application devs.
From an ease of use POV, I 100% agree with Roy, but ...
Actually, this is not about a specific browser, this is the only way
how any browser can deal with a file multipart upload so a dhtml
app can access its result.
The problem lies in some browser's "ability" to allow for kind of a
user-friendly error message. Instead of relying on the the server to
provide user-friendly messages, the browser display something they
think
is more user friendly. (Granted most error responses on the real-world
net are not user-friendly, mostly filled with stack traces or DB error
messages ....)
The concrete case is IE which allows setting a "Show friendly HTTP
error
messages" message flag (in the Advanced Tab of the Internet Options),
which hides the actual server response.
There is no way a server may find out about this situation. Hence the
workaround is for the client to set a flag to simulate a successfull
request and send back the actual status in the resulting HTML.
As this is really a workaround, which is used in one specific use
case,
it must be forced by setting a flag. Otherwise - and by default -, the
server will act standards-complying by sending back the correct status
code together with the full status response.
Regards
Felix
Since there is no client side trick (for security reasons) to do a
file upload other than a straight form POST (no xhr or anything)
and since there is no response code other than 200 and no
other way than the DOM of a text/html document that allows you
to transport the result of the POST (like let's say the "location"
after the 201) to a client-side app this is not a browser specific
workaround. I wish there was something else but browsers
are very consistent here. Frankly, I am not even sure what
browsers could do about that in the future.
regards,
david
