Bug 14831 - Status code of local failed GET request is different on Mac and Windows
Summary: Status code of local failed GET request is different on Mac and Windows
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: XML (show other bugs)
Version: 523.x (Safari 3)
Hardware: Macintosh OS X 10.4
: P2 Normal
Assignee: Nobody
Keywords: InRadar, PlatformOnly
: 14832 (view as bug list)
Depends on:
Blocks: 10489
  Show dependency treegraph
Reported: 2007-07-31 11:40 PDT by Jesse Costello-Good
Modified: 2008-06-23 16:34 PDT (History)
3 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Costello-Good 2007-07-31 11:40:35 PDT
var r = new XMLHttpRequest();
r.open("GET", "nowhere.html", false);
assertEquals(400, r.status);
Comment 1 Jesse Costello-Good 2007-07-31 11:50:31 PDT
*** Bug 14832 has been marked as a duplicate of this bug. ***
Comment 2 Alexey Proskuryakov 2007-07-31 13:37:02 PDT
What version is this a regression from? I'm getting the same result (-1100) in shipping 10.4.10 Safari/WebKit.

Clearly, it's wrong to expose a platform-specific error code as http status, but I would expect it to be 0 or 404 in this case. Do other browsers set the status of failed file:// request to 400?
Comment 3 Jesse Costello-Good 2007-07-31 14:43:37 PDT
Sorry for not being clear, sometimes it is difficult to figure out how Safari has changed given how much of our own code is written on top of it. 

What I meant to say is that Safari 3 beta 3.0.1 and the V3 branch up until that point throws an error for the code sample that I provided, while the latest nightlies just set the status code to -1100 on Mac and 112 on Windows.

Either throwing an error as in V3 beta or setting the status code to a consistent value in the 400s would be a fine resolution. 
Comment 4 Alexey Proskuryakov 2007-08-01 00:38:20 PDT
We no longer raise an exception in this case, because it broke some Dashboard widgets. I would really love to fix this in a sensible way, but we may have to make Windows port match Mac first, and only fix the behavior of both after Safari 3 (it seems too late to change Mac behavior now).

Other cases to verify are trying to access a local directory instead of a file, and permissions problems.
Comment 5 Mark Rowe (bdash) 2007-08-01 05:36:47 PDT
Comment 6 William J. Edney 2008-06-19 06:19:56 PDT
This was not a problem for me for the Safari 3.X series (i.e. the same 'failure' code was being used for both plaforms), but is now definitely a problem for the Safari 4.X developer preview. Safari/Windows is just returning a 404, whether the directory exists or not (I'm using this for 'directory existence detection').

Here is what I would propose (and which should obviously work cross-platform):

1. If the file:// URL points to a file and the file exists, the status code should return 200. The responseText/responseXML may very well be empty or null (meaning no content). If the file doesn't exist, it returns 404.

2. If the file://URL points to a directory and the directory exists (even if it has no files within it), the status code should return 200. If the directory doesn't exist, it returns 404.



- Bill
Comment 7 William J. Edney 2008-06-23 16:34:11 PDT
All -

I'll amend what I said earlier. It seems that this is also an issue for Safari/Windows 3.1X.

So Safari 3.1+ on Windows and Safari 4.0 developer preview all platforms are showing inconsistent and screwy values for this.


- Bill