Bug 6275 – XMLHttpRequest.getResponseHeader should return a null string for non-existent headers

• Status: RESOLVED
• Resolution: FIXED
• Component: XML

[Alexey Proskuryakov]

The current version of the Web Applications spec says so, and presumably this is how WinIE behaves. I 
cannot say that I find such behavior reasonable, though.

Firefox returns null, while Safari returns undefined.

<http://whatwg.org/specs/web-apps/current-work/>

[Alexey Proskuryakov]

Mozilla also documents a null returned value: <http://lxr.mozilla.org/seamonkey/source/extensions/
xmlextras/base/public/nsIXMLHttpRequest.idl#148>

[Rob Buis]

Just a remark, this is easily fixed by using jsString() instead of jsStringOrUndefined(), I verified
this. However ap reported to me that this spec is not settled...
Cheers,

Rob.

[Alexey Proskuryakov]

The draft spec is now at <http://www.w3.org/TR/XMLHttpRequest/>. I don't know if this specific provision is being disputed, but as long as Firefox doesn't comply, we probably needn't, as well.

[Anne van Kesteren]

Both IE7 and O9 pass that test. I'm not really convinced this should be changed in favor of F1.5 and S2.

[Anne van Kesteren]

So given your comments on IRC I suggest you raise this on [e-mail]. Including the fact that it's useful sometimes to distinguish between having a header not set at all and having it set to the emtpy string even though that's against the spirit of HTTP (if I understood Maciej correctly).

[Alexey Proskuryakov]

So, the draft specification was changed, correcting the summary accordingly.

[Alexey Proskuryakov]

Created attachment 11628 [details]
proposed patch

This patch modifies our copy of Hixie's test, which didn't conform to the updated draft spec.

[Geoffrey Garen]

Comment on attachment 11628 [details]
proposed patch

r=me!

[Alexey Proskuryakov]

Committed revision 18078.