[Dojo-interest] Rpc-JSON smd file cash question

[Alex Russell]

Hey Fredrik!

On Thursday 16 February 2006 2:07 pm, Fredrik Johansson wrote:
> Hi !
>
> I been playing around with Rpc-JSON and I have noticed a strange
> thing, when I try the test_JsonService examples in tests dir from
> apache It works in all my browsers. However if I reload the page It
> breaks in konqueror-3.5.1, dont know about konq versions before this.
> If I resave the testClass.smd file on the server so that it gets a
> new timestamp it works for the first reload of the page, next reload
> is broken again.

Hrm. We could change the bind() the fetches the SMD to send the 
cache-buster parameter, but that seems heavy-handed. Esp because a 
cached SMD would seem like a *very good* thing.

> As cache obviously is the isue here I did some netsniff with
> etherreal, and I get a http status: "304 not modified" in the
> response header.
>
> dojo.io.BowserIO doLoad doesnt take a 304 http.status as a valid
> response so it gets pushed onto error reporting instead.
>
> Changing:
> --- BrowserIO.js    (revision 3072)
> +++ BrowserIO.js    (arbetskopia)
> @@ -258,8 +258,8 @@
>      }
>
>      // moved successful load stuff here
> -    function doLoad(kwArgs, http, url, query, useCache) {
> -        if((http.status==200)||(location.protocol=="file:" &&
> (http.status==0
>
> || http.status==undefined))) {
>
> +    function doLoad(kwArgs, http, url, query, useCache)
> {dojo.debug("http.status: "http.status);
> +        if((http.status==200)||(http.status==304)||
> (location.protocol=="file:" && (http.status==0 ||
> http.status==undefined))) { var ret;
>              if(kwArgs.method.toLowerCase() == "head"){
>                  var headers = http.getAllResponseHeaders();
>
>
> Fixes this so that a 304 is considered valid response.
> The dojo.debug("http.status: "+http.status) on (my change) line 258
> reports 200 on every browser exept konqueror.
> Even firefox-1.5 says its status 200 even though my ethereal capture
> tells me its 304, I thought that firefox 1.5 cached xmlhttp requests
> as well, no?

It should, but in that case it might not even hit the wire if the local 
cache can handle the request and the cache control and expiry headers 
don't require a freshness check.

> So my question is:
> Should this be considered as a browser bug or not? 

Yes, I think so, but your patch seems reasonable. It's implemented as 
SVN r3083. I do wonder if we should also handle the 302 case, but I 
don't suppose it makes sense to deal with that until we hit it.

> (and/or dojo bug) 
> khtml does return what the server reports, firefox, opera and ie does
> not. I mean IF firefox-1.5 indeed has cache in XmlHttpRequest
> should'nt it return a 304 like apache tells it to?

Sure, but why should the client have to know that it "wasn't changed" vs 
"got the content"? They're the same semantic, so the browser lying to 
JS actually makes some sense.

> Hope you can make sence out of my textblurb above..
> / Fredrik Johansson

And thanks for digging in and figuring out what was going on!

Regards

-- 
Alex Russell
alex at jot.com
alex at dojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723