Bug 7385 – XMLHttpRequest 304 "not modified" status not returned in asynchronous mode

• Status: RESOLVED
• Resolution: INVALID
• Component: XML

[Sen Haerens]

via http://bugzilla.opendarwin.org/show_bug.cgi?id=3810#c8

When parsing static XML files and sending the correct if-modified-since header the server returns 304 but the XMLHttpRequest status returns undefined. In synchronous mode 304 is returned.

Secondly setting a null value in the content method seems to make a difference. According to http://developer.apple.com/internet/webcontent/xmlhttpreq.html this value is optional. 

With null filled in there’s no traffic anymore between the browser and the server (tcpflow shows this clearly) and the status code varies from undefined to -1007. There must be some internal caching in this case.

[Sen Haerens]

Testcase added.

[Eric Seidel (no email)]

Could this be a dup of http://bugzilla.opendarwin.org/show_bug.cgi?id=3810 ?

[Alexey Proskuryakov]

I think that I did a poor job of explaining my thoughts in bug 3810 comment 8 :(. I'll file a new bug for that myself.

The problem with setting a null value sounds new to me, I'll look into it.

[Alexey Proskuryakov]

I have filed the problem where NSURLConnection returns -1007 as <rdar://4457674>. This doesn't explain all the issues we see, though.

I cannot notice any difference between send(), send(null), and send(""), could you please describe your results in more detail? Is this GET or POST (I assume the former)? Please also note that shipped Safari and ToT WebKit have different behavior - the latter would never return a negative status, replacing it with undefined.

[Sen Haerens]

(In reply to comment #4)
> I cannot notice any difference between send(), send(null), and send(""), could
> you please describe your results in more detail? Is this GET or POST (I assume
> the former)? Please also note that shipped Safari and ToT WebKit have different
> behavior - the latter would never return a negative status, replacing it with
> undefined.

I can't seem to reproduce it either for the moment. Safari used was the stock 2.0.3 (417.8). I will do some more testing next week.

[Alexey Proskuryakov]

Still no steps to reproduce, closing as INVALID.

Please note that the behavior of conditional XHR requests has been significantly changed as a result of bug 8210, which may fix the original concern here.