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
