Any XHR response has the property `statusText` hardcoded to "OK", instead of the correct string corresponding to the response's `statusCode` property. This breaks RFC2616.
The attached patch fixes this on the Mac platform. The correct fix would be adding a `responseText` method to NSHTTPURLResponse, but this is out of my reach. I filed radr://7227480, though.
The formatting of the case statement is deliberately diverging from the coding standards for readability. I hope you agree with my choice. If not, I'm happy to make a coding standards compliant version.
I added a simple test case for this patch and fixed another test case that relied on the broken behaviour.
Please let me know if you need any more information.
Created attachment 39654 [details]
implements the described issue.
I don't think it's helpful to fake response status text - the one case when web apps need to know it is when it's non-default, and this patch makes it more difficult to detect the broken WebKit behavior.
*** This bug has been marked as a duplicate of bug 24572 ***
Sorry for filing a duplicate. My search for "responseText" didn't show #24572 (https://bugs.webkit.org/buglist.cgi?quicksearch=responseText). I don't think I understand Alexey's reasoning. This is a bug that makes WebKit behave non RFC conform and I don't see a good reason to not fix it except "too many people depend on it".
I understand that the open web is not the only target for WebKit users and that in some environments WebKit is the only engine to program against, but I believe the majority of users could do with the correct behaviour. Especially when it is only "wrong" on the Mac platform.
I also don't think this is "faking" response codes, it is just adding the correct ones.
This is definitely a bug that should be fixed, but we need support from NSHTTPURLResponse to do that.
There is no such thing as "correct" status text - the server may well respond with "HTTP/1.1 500 Please reboot me", for example.