[Webkit-unassigned] [Bug 54162] XHR inconsistent in handling access to response attributes after an error

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon Feb 14 16:45:28 PST 2011


https://bugs.webkit.org/show_bug.cgi?id=54162





--- Comment #9 from Jarred Nicholls <jarred.nicholls at gmail.com>  2011-02-14 16:45:29 PST ---
(In reply to comment #7)
> This change has affected SAP in the past. SAP sends Firefox code to Safari, but I don't know what their use case is exactly.
> 
> We should probably try changing the XHR2 spec at this point, although it's a bit late in the game. It doesn't really make a lot of sense to reset status on abort().

Yeah, perhaps.  This route was chosen because 1) it's how IE works, and 2) it's what the spec says.  The important thing is consistency across the board...it's just a pet peeve of mine.  I don't care if we went 180 degrees in the opposite direction and follow Firefox, and allow access to status, statusText, getAllResponseHeaders, and getResponseHeader after an abort :)  But this patch is not just about abort(), it's about all errors and returning the proper response types (i.e. not throwing an exception, or return "" instead of null, etc.).

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list