Safari/konqueror caching bug

[jwashin@…]

With browser cache enabled in many versions of Safari and Konqueror, second and subsequent requests for cacheable items will fail. For example, if a page is reloaded, as happens a lot in development, things break that previously worked, which causes much anxiety. The problem is that http.status not defined in this situation for these browsers, though the responseText will be available if requested. Dojo code (0.3) looks for defined status codes for acceptance of the responseText, so these requests fail silently in this situation. No 404. Just broken. This is maybe a bug in the khtml code, but there are a lot of browsers out there with this bug, so it would be nice if dojo made a small work-around to this for supporting these browsers.

work-arounds:

~line 231 of src/io/BrowserIO.js:

add

(http.responseText)

if((http.status==200)

(http.status==304)	(http.status==204)	(http.responseText)
(location.protocol=="file:" && (http.status==0

~line 168 of src/hostenv_browser.js

remove status check in first conditional and insert check for responseText

if(4==http.readyState){

if(http.status==200

http.responseText){

There are perhaps other ways to do this, but the essential idea is to retrieve the http.responseText when http.status is undefined and http.responseText is defined. That is the situation for these browsers when the data is coming from the browser cache.

[James Burke]

I thought testing for http.status == 0 is sufficient for the Safari cache case. dojo.hostenv.getText() in hostenv_browser.js is not using that check, but right now the only uses of the function within Dojo are for synchronous use (not using the callback). And code outside of Dojo should not be calling dojo.hostenv.getText(). dojo.io.bind() is the preferred public interface.

dojo.io.bind() does not check for status == 0 by itself, but my initial try at a cache test for Safari seemed to work. However, I may have been setting the wrong headers (I'm using Cache-Control: max-age=2592000, and Expires: Sat, 01 Jul 2006 00:08:16 GMT (a one month cache time)).

Could you provide more information, possible a test case? What Dojo calls in particular failed? For the HTTP headers, what are you using to indicate that the page is cacheable?

[mumme]

I'm seeing something related to this in my fresh apache install, I get a 304 not modified http.status.

Dont know why I havent seen it before, will investigate some more when I got time

/ Fredrik

[mumme]

Hi,

I just checked in a fix for the 304 case in hostenv_browser.js. Are realy sure the http.responseText is needed, I agree that package loading was broken before in khtml.

I cant test in safari, just konqueror and it works fine in 3.5.3

Regards Fredrik Johansson

[mumme]

There doesnt apear to be any issues, at least non I heard of, after the 304 checkin.

The reason why we are hesitant for the responseText check is that it would be hard to distinguish a server error from a valid response, think of a 500 internal server error or a 404 page not found, both will produce responseText yet they are'nt valid responses.

Please reopen if issue still occur.

/ Fredrik

[(none)]

Milestone 0.4 deleted