MSXML HTTP translates response status code 204 to 1223
in [JavaScript]
|
From: Stefan Weiss on 7 Sep 2009 19:50 On 07/09/09 19:33, Thomas 'PointedEars' Lahn wrote: > As described e.g. in [2], contrary to the MSDN Library documentation[3], the > IXMLHTTPRequest implementation in MSXML HTTP (at least in IE 8.0 on Windows > XP SP3+) does not handle HTTP responses with status code 204 (No Content) > properly; the `status' property has the value 1223 then (which I found out > thanks to IE 8.0's built-in debugger). [snip] > status: { > /* > * NOTE: MSXML translates 204 to 1223, see > * https://prototype.lighthouseapp.com/projects/[...] > */ > OK_EXPR: /\b(0|2\d\d|1223)\b/, > > // ... > } Yes, this rings a bell. I must have run into the same thing, because the code I (re)use for XHR related tasks has this function: function httpStatusOk (status) { return (status >= 200 && status < 300 // 200-299: HTTP OK range || status == 304 // HTTP Not Modified || status == 1123 // MSIE Bug (should be 204) || !status); // !status: local file access or Safari bug } I haven't thought about this part of the library in a while, but looking at it now, it seems to me that a 304 response probably should be handled separately. The "status" map from your httprequest.js appears to be more detailed, and doesn't group all of those values together. I'll be sure and take a look at it if/when you release it. Thanks for the links. cheers, stefan
From: Thomas 'PointedEars' Lahn on 8 Sep 2009 13:14 Stefan Weiss wrote: > Thomas 'PointedEars' Lahn wrote: >> status: { >> /* >> * NOTE: MSXML translates 204 to 1223, see >> * https://prototype.lighthouseapp.com/projects/[...] >> */ >> OK_EXPR: /\b(0|2\d\d|1223)\b/, >> >> // ... >> } > > Yes, this rings a bell. I must have run into the same thing, because the > code I (re)use for XHR related tasks has this function: > > function httpStatusOk (status) { > return (status >= 200 && status < 300 // 200-299: HTTP OK range > || status == 304 // HTTP Not Modified > || status == 1123 // MSIE Bug (should be 204) ^^^^ Is this a copypaste error or am I seeing a bug here? Should be _1223_. > Thanks for the links. You're welcome. PointedEars -- realism: HTML 4.01 Strict evangelism: XHTML 1.0 Strict madness: XHTML 1.1 as application/xhtml+xml -- Bjoern Hoehrmann
From: Stefan Weiss on 8 Sep 2009 23:27 On 08/09/09 19:14, Thomas 'PointedEars' Lahn wrote: > Stefan Weiss wrote: >> function httpStatusOk (status) { >> return (status >= 200 && status < 300 // 200-299: HTTP OK range >> || status == 304 // HTTP Not Modified >> || status == 1123 // MSIE Bug (should be 204) > ^^^^ > Is this a copypaste error or am I seeing a bug here? Should be _1223_. Typo, thanks. I had to shrink the function before posting so that it wouldn't wrap, and apparently changed the value while doing so. By the way, I just found the 1223 value in JQuery*, but not in YUI or Prototype. cheers, stefan * (disclaimer: not an endorsement, yadda yadda...)
From: kangax on 9 Sep 2009 12:52 Thomas 'PointedEars' Lahn wrote: > Hello, > > I do not know if this is really news to you, but since I have encountered > it not before today in one of my commercial projects (XHR had not been a > priority there), and a Google Groups search here for "1223" returned it only > once in a rather long posting of Conrad Lender that advocates browser > sniffing to deal with this kind of problem[1], I thought I could as well > tell you about it. It was reported to Prototype a little more than a year ago (May 30th, 08) - <https://prototype.lighthouseapp.com/projects/8886/tickets/129-ie-mangles-http-response-status-code-204-to-1223> By that time it was already in jQuery and YUI (as you can see me mentioning it in a comment - <https://prototype.lighthouseapp.com/projects/8886/tickets/129-ie-mangles-http-response-status-code-204-to-1223#ticket-129-2>) jQuery has it for about 2 years now, YUI - even longer. > > In a nutshell: > > As described e.g. in [2], contrary to the MSDN Library documentation[3], the > IXMLHTTPRequest implementation in MSXML HTTP (at least in IE 8.0 on Windows > XP SP3+) does not handle HTTP responses with status code 204 (No Content) > properly; the `status' property has the value 1223 then (which I found out > thanks to IE 8.0's built-in debugger). The used ActiveX/COM ProgID to > reproduce the bug was "Microsoft.XMLHTTP" which should select MSXML 3.0 or > earlier (AFAIK).[4] > > As a result, I have changed > > status: { > OK_EXPR: /\b(0|2\d\d)\b/, > > // ... > } > > into > > status: { > /* > * NOTE: MSXML translates 204 to 1223, see > * https://prototype.lighthouseapp.com/projects/[...] > */ > OK_EXPR: /\b(0|2\d\d|1223)\b/, Don't you think regex is really a wrong tool for the job in this case? It would be much more clear and efficient to perform a plain number comparison. E.g., quoting YUI, <http://github.com/yui/yui3/blob/7f5d4982cb5e88b379f9b3b8bea8e3acf810a511/src/io/js/io-base.js#L671> if (status >= 200 && status < 300 || status === 1223) { // ... } else { // ... } [...] -- kangax
From: Thomas 'PointedEars' Lahn on 9 Sep 2009 13:38
kangax wrote: > Thomas 'PointedEars' Lahn wrote: >> I do not know if this is really news to you, but since I have encountered >> it not before today in one of my commercial projects (XHR had not been a >> priority there), and a Google Groups search here for "1223" returned it only >> once in a rather long posting of Conrad Lender that advocates browser >> sniffing to deal with this kind of problem[1], I thought I could as well >> tell you about it. > > It was reported to Prototype a little more than a year ago [...] I know. Read again: >> In a nutshell: >> >> As described e.g. in [2], contrary to the MSDN Library documentation[3], the ^^^^^^^^^^^^^^^^^^^^^^^^ >> IXMLHTTPRequest implementation in MSXML HTTP (at least in IE 8.0 on Windows >> XP SP3+) does not handle HTTP responses with status code 204 (No Content) >> properly; the `status' property has the value 1223 then (which I found out >> thanks to IE 8.0's built-in debugger). The used ActiveX/COM ProgID to >> reproduce the bug was "Microsoft.XMLHTTP" which should select MSXML 3.0 or >> earlier (AFAIK).[4] >> >> As a result, I have changed >> >> status: { >> OK_EXPR: /\b(0|2\d\d)\b/, >> >> // ... >> } >> >> into >> >> status: { >> /* >> * NOTE: MSXML translates 204 to 1223, see >> * https://prototype.lighthouseapp.com/projects/[...] >> */ >> OK_EXPR: /\b(0|2\d\d|1223)\b/, > > Don't you think regex is really a wrong tool for the job in this case? No. Here I have the positive (and negative) cases composed into one "constant"; for considering MSXML's quirk now, I did not need to modify the code of a single method. Think about it. > It would be much more clear and efficient to perform a plain number > comparison. As for clarity, I don't think so. As for efficiency, maybe; but iff number comparison is more efficient, is the difference really relevant? > E.g., quoting YUI, > <http://github.com/yui/yui3/blob/7f5d4982cb5e88b379f9b3b8bea8e3acf810a511/src/io/js/io-base.js#L671> > > if (status >= 200 && status < 300 || status === 1223) { Yes, I know that and I don't like it at all. PointedEars -- var bugRiddenCrashPronePieceOfJunk = ( navigator.userAgent.indexOf('MSIE 5') != -1 && navigator.userAgent.indexOf('Mac') != -1 ) // Plone, register_function.js:16 |