21

I'm using HttpClient 0.6.0 from NuGet.

I have the following C# code:

var client = new HttpClient(new WebRequestHandler() {
    CachePolicy =
        new HttpRequestCachePolicy(HttpRequestCacheLevel.CacheIfAvailable)
});
client.GetAsync("http://myservice/asdf");

The service (this time CouchDB) returns an ETag value and status code 200 OK. There is returned a Cache-Control header with value must-revalidate

Update, here are the response headers from couchdb (taken from the visual studio debugger):

Server: CouchDB/1.1.1 (Erlang OTP/R14B04)
Etag: "1-27964df653cea4316d0acbab10fd9c04"
Date: Fri, 09 Dec 2011 11:56:07 GMT
Cache-Control: must-revalidate

Next time I do the exact same request, HttpClient does a conditional request and gets back 304 Not Modified. Which is right.

However, if I am using low-level HttpWebRequest class with the same CachePolicy, the request isn't even made the second time. This is the way I would want HttpClient also behave.

Is it the must-revalidate header value or why is HttpClient behaving differently? I would like to do only one request and then have the rest from cache without the conditional request..

(Also, as a side-note, when debugging, the Response status code is shown as 200 OK, even though the service returns 304 Not Modified)

NiklasN
  • 559
  • 1
  • 7
  • 12
  • Caching is not trivial. Can you update your post with the request headers of the both calls? – Asken Dec 09 '11 at 12:56
  • I don't think request headers are that necessary in this case. As I'm confused why HttpClient even does that second call (compared to HttpWebRequest, which only does one call). – NiklasN Dec 09 '11 at 12:59
  • 1
    It's normally ONLY the headers that matters in terms of what the server is sending you. – Asken Dec 09 '11 at 13:05
  • Oh you meant response headers? I'll update those.. – NiklasN Dec 09 '11 at 13:11
  • What is the value of of the must-revalidate header that you refer to? – Rowland Shaw Dec 09 '11 at 13:12
  • The service would return the same thing it the request was the same. Therefor have a look at the request headers in both cases. There must be a difference between the two. – Asken Dec 09 '11 at 13:17
  • Asken, the problem isn't what the response are. It's that with HttpWebRequest there **is no** second request. And I would like to HttpClient behave the same. Only ask one time.. – NiklasN Dec 09 '11 at 13:18
  • Updated the question with the headers.. – NiklasN Dec 09 '11 at 13:18

2 Answers2

28

Both clients behave correctly.

must-revalidate only applies to stale responses.

When the must-revalidate directive is present in a response received by a cache, that cache MUST NOT use the entry after it becomes stale to respond to a subsequent request without first revalidating it with the origin server. (I.e., the cache MUST do an end-to-end revalidation every time, if, based solely on the origin server's Expires or max-age value, the cached response is stale.)

Since you do not provide explicit expiration, caches are allowed to use heuristics to determine freshness.

Since you do not provide Last-Modified caches do not need to warn the client that heuristics was used.

If none of Expires, Cache-Control: max-age, or Cache-Control: s- maxage (see section 14.9.3) appears in the response, and the response does not include other restrictions on caching, the cache MAY compute a freshness lifetime using a heuristic. The cache MUST attach Warning 113 to any response whose age is more than 24 hours if such warning has not already been added.

The response age is calculated based on Date header since Age is not present.

If the response is still fresh according to heuristic expiration, caches may use the stored response.

One explanation is that HttpWebRequest uses heuristics and that there was a stored response with status code 200 that was still fresh.

Pavel Gatilov
  • 7,579
  • 1
  • 27
  • 42
Hans Malherbe
  • 2,988
  • 24
  • 19
-2

Answering my own question..

According to http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.4 I would say that a "Cache-Control: must-revalidate" without expiration states that the resource should be validated on every request.

In this case it means a conditional GET should be done every time the resource is made. So in this case System.Net.Http.HttpClient is behaving correctly and the legacy (Http)WebRequest is doing invalid behavior.

NiklasN
  • 559
  • 1
  • 7
  • 12
  • 2
    This is not correct, the spec doesn't say that. The correct answer [has been given by Hans Malherbe](http://stackoverflow.com/a/9228743/795861) – Pavel Gatilov Sep 28 '12 at 11:57