c# - Comportamiento de caché de System.Net.Http.HttpClient

wcf couchdb

Question

Estoy usando HttpClient 0.6.0 de NuGet.

Tengo el siguiente código de C #:

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

El servicio (esta vez CouchDB) devuelve un valor ETag y el código de estado 200 OK. Se devuelve un encabezado Cache-Control con valor debe-revalidar

Actualización, aquí están los encabezados de respuesta de couchdb (tomados del depurador de Visual Studio):

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

La próxima vez que haga exactamente la misma solicitud, HttpClient hace una solicitud condicional y vuelve a 304 Not Modified. Lo cual está bien.

Sin embargo, si uso la clase HttpWebRequest de bajo nivel con la misma CachePolicy, la solicitud ni siquiera se realiza la segunda vez. Esta es la forma en que me gustaría que HttpClient también se comporte.

¿Es el valor del encabezado must-revalidate o por qué HttpClient se comporta de manera diferente? Me gustaría hacer solo una solicitud y luego tener el resto de la memoria caché sin la solicitud condicional.

(Además, como nota al margen, al depurar, el código de estado de la respuesta se muestra como 200 OK, aunque el servicio devuelve 304 Not Modified)

Answer 1

Respondiendo a mi propia pregunta ...

De acuerdo con http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.4 Diría que un "Cache-Control: must-revalidate" sin vencimiento establece que el recurso debe ser validado en cada solicitud.

En este caso, significa que se debe hacer un GET condicional cada vez que se hace el recurso. Entonces, en este caso, System.Net.Http.HttpClient se está comportando correctamente y el legado (Http) WebRequest está haciendo un comportamiento no válido.

Answer 2

Ambos clientes se comportan correctamente.

must-revalidate solo se aplica a las respuestas obsoletas .

Cuando la directiva must-revalidate está presente en una respuesta recibida por un caché, ese caché NO DEBE utilizar la entrada después de que quede obsoleta para responder a una solicitud posterior sin antes revalidarla con el servidor de origen. (Es decir, la memoria caché DEBE realizar una revalidación de extremo a extremo cada vez, si , basándose únicamente en el valor Expira o en el valor máximo de validez del servidor de origen, la respuesta en caché no es correcta ).

Dado que no proporciona expiración explícita, las memorias caché pueden usar heurística para determinar la frescura .

Como no proporciona cachés Last-Modified , no es necesario que advierta al cliente que se utilizó heurística.

Si ninguno de Caduca, Cache-Control: max-age, o Cache-Control: s-maxage (vea la sección 14.9.3) aparece en la respuesta, y la respuesta no incluye otras restricciones en el almacenamiento en caché, la caché PUEDE calcular una frescura vida útil usando una heurística . La memoria caché DEBE adjuntar la Advertencia 113 a cualquier respuesta cuya edad sea superior a 24 horas si dicha advertencia no se ha agregado aún.

La edad de respuesta se calcula en función del encabezado de la Date ya que la Age no está presente.

Si la respuesta aún es reciente según la caducidad heurística, las memorias caché pueden usar la respuesta almacenada.

Una explicación es que HttpWebRequest usa heurística y que había una respuesta almacenada con el código de estado 200 que aún estaba fresco.