locked
WinJS.xhr caches responses and ignores cache-control response headers which say not to.

    Question

  • I'm trying to use WinJS.xhr to make an AJAX call to a server I don't really have direct control over, and it works just fine the first time but then every subsequent call returns the same data, almost certainly due to caching of the response (the URL is the same every time, just to be clear).

    Here's a simplified example of what I'm doing:

    WinJS.xhr({url: serverURL,
    headers: {"Cache-Control": "no-cache", "If-Modified-Since": "Mon, 27 Mar 1972 00:00:00 GMT"},
    user: username,
    password: password}).done(
    function (request){
    do something},
    function (request){
    handle errors});

    The server's response headers are:

    Cache-Control:must-revalidate, no-cache, no-store
    Connection:close
    Content-Length:19
    Content-Type:application/json;charset=utf-8
    Date:Mon, 23 Jul 2012 09:48:26 GMT
    Expires:0
    Pragma:no-cache


    I suspect that the reason "If-Modified-Since" doesn't work is that the response doesn't include a "Last-Modified" field, but I can't really do anything about it without having access to the server code. That said, the cache-control fields that are set in the response headers should tell WinJS.xhr not to cache the response but it doesn't seem to listen to them. I'm not sure if this is intended behavior or a bug.

    Has anyone encountered the same issue? Have you managed to convince WinJS.xhr to clear its cache or not keep one?


    • Edited by Ilia Koulinitch Monday, July 23, 2012 5:50 PM Fixed some formatting.
    Monday, July 23, 2012 5:49 PM

Answers

  • Correct.  If you see the request go out and a response come back with the same old stale data, your server is sending the same old stale data.

    Jeff Sanders (MSFT)

    Tuesday, July 24, 2012 2:31 PM
    Moderator

All replies

  • Cache-Control is a response header so do not set it in the request.

    Use fiddler to see what is being sent and returned by the server:

    http://blogs.msdn.com/b/fiddler/archive/2011/09/14/fiddler-and-windows-8-metro-style-applications-https-and-private-network-capabilities.aspx

    Let's see what is sent out and received!

    -Jeff


    Jeff Sanders (MSFT)

    Monday, July 23, 2012 7:16 PM
    Moderator
  • Looking at the requests and responses in Fiddler (neat tool, by the way; it's very useful), it seems that the server response headers don't actually set the cache-control headers (or at least it's not recognized, even in Fiddler). That combined with the lack of a Last-Modified value explains why the caching is happening every time.

    I was assuming that it was the server returning headers with cache-control, but I now suspect that those values were being injected by other AJAX functions I was using before (calls to the same server from other non-Windows apps using different AJAX methods) as a side effect of using authentication. It seems I'll have to try to get the server's response headers changed before I can find out that WinJS.xhr (hopefully) respects them.

    Thank you very much for helping me get on the right track to find where the error really lies, Jeff.

    Monday, July 23, 2012 8:48 PM
  • You are welcome!

    Be aware that proxies can also strip out or misbehave with caching.  Also do you see a request go out when you suspect that xhr is caching?

    -Jeff


    Jeff Sanders (MSFT)

    Tuesday, July 24, 2012 11:51 AM
    Moderator
  • I do see the first and all subsequent requests show up in Fiddler. It shows authorization data changing between requests, which is correct. There's also a JSESSIONID cookie that is same between requests, and the connection is set to "keep-alive". None of these are things I would necessarily want to persist between requests, but I don't know how relevant they are either. Is it possible that the server just assumes that since the session is the same, the same data should be sent again even if the authorization data is changed?

    From the behavior, I was quick to suspect caching; even Fiddler's caching tab warns me that the response is cacheable by default and that a lack of a Last-Modifed value prevents a conditional revalidation of the response.

    Does the fact that the subsequent requests show up in Fiddler point to caching not being the issue (i.e. the server is just sending the same data back due to session cookies, and it's not being cached at all)?

    Tuesday, July 24, 2012 2:27 PM
  • Correct.  If you see the request go out and a response come back with the same old stale data, your server is sending the same old stale data.

    Jeff Sanders (MSFT)

    Tuesday, July 24, 2012 2:31 PM
    Moderator
  • Is it possible that's a result of the session being saved? If so, do you know of a way to disable the storage of (or clear) a cookie associated with an ajax request?
    Tuesday, July 24, 2012 2:37 PM
  • If a cookie is being re-used it is obeying the cookie handling rules.  You cannot manually affect cookies so you will need to fix the server to send the correct expires headers.

    Jeff Sanders (MSFT)

    Tuesday, July 24, 2012 2:55 PM
    Moderator
  • I figured it'd require a change on the server side. Thanks again for your help, Jeff.
    Tuesday, July 24, 2012 3:08 PM