Consider headers in '$http' cache

[filiptc]

The current $http cache takes only the url as key. Consider the case where a call to the API uses the 'Range' header for pagination and cache is set to true. All requests to the same url with different pagination will return the first cached response to the inital page. IMHO headers are a defining part of the request, just like the url, and should therefore be included in the cache key.

Are there plans to include this? Would you accept a pull request?

[aj-dev]

I agree that Range header should be taken into consideration when using $http cache. Currently there is no easy way to cache paginated results where Range header is used.

[IgorMinar]

which headers should we consider?

should this list of headers be part of the request config object or should we just try our best to emulate http?

I'm not keen on emulating http.

[aj-dev]

I think the header in question is Range header and it should be part of request config object. Some example use cases with $resource:

var User = $resource('http://test.me/users', {}, {
        query: {
            method: 'GET',
            isArray: true,
            headers: {'Range': '0-9'} // request 10 users only where 0 is start index and 9 is end index
        }
    });

// Using transformRequest
var User = $resource('http://test.me/users', {}, {
        query: {
            method: 'GET',
            isArray: true,
            transformRequest: function (data, headersGetter) {
                var headers = headersGetter();
                headers['Range'] = '0-9';
            },
            transformResponse: function (data, headersGetter) {
                var contentRange = headersGetter('content-range'); // contains '0-5/6' where 0 is start index, 5 - end index and 6 is total number of results
                return angular.fromJson(data);
            }
        }
    });

[aj-dev]

Are there any updates on this?

Range header pagination is gaining more popularity now as it allows us to have clean responses that don't need further filtering in AngularJS to remove the clutter that the usual pagination contains; data can be immediately injected into Angular apps, modified and sent back to a server retaining the same clean structure.

Here's an example of pagination module using Range header: https://github.com/begriffs/angular-paginated-resource

Caching Range header would be a significant improvement in Angular.

[caitp]

@aj-dev, headers are cached already. https://github.com/angular/angular.js/blob/master/src/ng/http.js#L956 << when serving a cached response, the headers are plucked out of the cache as well.

The issue is, if you want to make subsequent requests, you'd need to delete the object from the cache before you did, so that's an extra step to remember.

[aj-dev]

@caitp,
Sorry, I meant Range header should not be cached or its content should be compared to a cached version in subsequent requests as per @filiptc comment above. Are there any plans to support this in the near future?

[caitp]

No, that's not likely to happen. You can simply remove the item from cache, since the data would stop being valid anyways

[filiptc]

@caitp What a shame... That would mean dispensing with any cache for those scenarios. =(

[caitp]

Do you have any proposals on how it should work?

[filiptc]

Well, I don't know what would be the best way to implement this. As I mentioned in my first post, maybe to serialize certain arbitrary headers (or just range) and include them in the cache index so that each cache key is unique given a combination of a url and the selected headers.

[caitp]

We don't really have a nice O(1) way to say "get me the cached entry for this url with these headers set to these values, and ignore the other headers", which is why this is sort of troubling. Hardcoding specific headers would be bad and would almost certainly bite in the ass later on one way or another, but I'm not totally sure what data structure and algorithm would work well for this.

It would also have to fit into the existing cache system, which might be even harder.

[filiptc]

I understand. Maybe another option is providing a hook to register a custom function for setting cache indices and addressing cached content. At least that way there is an option for adding specific headers to the cache index.

[pixelcort]

Isn't this what the Vary header is for? Then just use the headers indicated in the Vary header into consideration for unique caching.