Reputation: 1144
I am using https://github.com/filipw/AspNetWebApi-OutputCache NUGET package to manage caching for my ASP.NET WEB API.
The server side caching works well. However I don't see it working on my browser (client side).
On request I see that max-age and etag is being returned.
However I make further request I don't see etag being supplied with request header with if-non-match parameter. This is why I get response 200 (OK) back with response data. It should have parsed data from cache itself.
https://dl.dropboxusercontent.com/u/2781659/stackoverflow/Cache.jpg
Can anybody please advise?
Upvotes: 0
Views: 427
Reputation: 14995
I just briefly looked at the Github project you referenced, and I wanted to throw in my $0.02, for whatever it's worth -
Breeze.js is responsible for taking care of client side caching for you. The idea is to not have to worry about what the back-end is doing and simply make a logical decision on the client on whether to proceed and hit the server for data again. If you don't need to refresh the data, then never hit the server, just return from Breeze's cache.
The project you are referencing seems to do both - server side and client-side caching. The decision of caching on the server is one not to be taken lightly, but this project seems to handle it pretty well.
The problem is that you are trying to mix two libraries which, at best, conflict in the area of what their concerns are. There may be a way to marry the two up, but at what cost? Why would you need to cache on the server that which is already cached on the client? Why cache on the client if you plan to cache the exact same data on the server?
The only reason I can think of is for paging of data (looking at a subset of the whole) and wanting to see the next data set without having to hit the server again. In that case, your query to the server should not match the original anyway and therefore one would expect that you need to customize the two solutions to do what you are asking for.
In general that project seems to ignore queryString parameters, from what I can tell, to support JSONP so you should have no problem coming up with a custom solution, if you still think that is necessary.
Upvotes: 1