From: Stefan Weiss on
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
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
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
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
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