FamilySearch/fs-js-lite

Response body not available on cached responses

Closed this issue · 4 comments

Response bodies are not being made available on cached responses.

A request is made for a person /platform/tree/persons/PPPP-PPP and is cached because an etag is present on the response. The next time a request is made for that person a 304 with an empty body is returned by the API. In this case, XHR is supposed to return a 200 to JavaScript and include the cached body.

For 304 Not Modified responses that are a result of a user agent generated conditional request the user agent must act as if the server gave a 200 OK response with the appropriate content.

But that's quoting a discontinued spec. The new living spec doesn't immediately appear to address caching.

I'm seeing this behavior on Chrome 54, Firefox 49, and Edge 38/14 on Windows.

The issue doesn't appear to afflict the old JavaScript SDK but it does afflict all browsers so it's not a browser bug.

I've noticed that subsequent responses are actually returning a 200 status instead of a 304. That may be due to the X-Expect-Override header.

I confirmed that it's being caused by the X-Expect-Override header. I'll have to find a work around.

The SDK currently applies the X-Expect-Override header on all requests so that it doesn't have to examine the URL to guess when you might want it and so that the user doesn't have to figure out when they need it.

I don't know if the API will recognize this as a bug, and even if they do it may be a while until it gets fixed. I want to wait for a response from them on the matter before deciding on a permanent solution. Until then, request middleware can be used to remove the header when it shouldn't be there.

// Add any others you may need to this list
var redirectPaths = [
    '/platform/tree/current-person',
    '/platform/users/current'
];
client.addRequestMiddleware(function(client, request, next){
    var redirectResource = false;
    for(var i = 0, redirectResource = false; i < redirectPaths.length && !redirectResource; i++){
        if(request.url.indexOf(redirectPaths[i]) !== -1){
            redirectResource = true;
        }
    }
    if(!redirectResource){
        delete request.headers['X-Expect-Override'];
    }
    next();
});

BTW, any responses that were previously cached when the bug was manifested will remain corrupt (not have the body) until the cache is cleared.

The API was updated to ignore X-expect-override on 304s.