HTTP If-None-Match vs. If-Match
caching header (1)
If-Match
El servidor DEBE devolver una respuesta 412 (falla previa a la condición), si:
- ninguna de las etiquetas de entidad coincide,
- o se da "*" y no existe entidad actual
If-Match se debe ignorar, si:
- cualquiera de las etiquetas de entidad coincide
- o si la solicitud resulta en algo que no sea un estado 2xx o 412 (sin If-Match)
- o si se da "*" y existe una entidad actual para el recurso
Conclusión sobre si-partido :
- El significado de "If-Match: *" es que el método debe realizarse si la representación seleccionada por el servidor de origen ... existe, y no debe realizarse si la representación no existe.
Si-Sin modificaciones-Desde
El servidor DEBE devolver una respuesta 412 (falla previa a la condición), si:
- la variante solicitada ha sido modificada desde el tiempo especificado
If-Unmodified-Since se debe ignorar, si
- el recurso solicitado no ha sido modificado desde el tiempo especificado en este campo
- o la solicitud normalmente (es decir, sin el encabezado If-Unmodified-Since) daría como resultado un estado que no sea 2xx o 412
- o la fecha especificada no es válida
If-Unmodified-Since en RFC2616
If-Range
Informalmente, su significado es ''si la entidad no cambia, envíeme la (s) parte (s) que me falta; de lo contrario, envíeme toda la nueva entidad ''
Condiciones previas:
- El encabezado
If-Range
DEBE usarse solo junto con un encabezado deRange
, y DEBE ignorarse si la solicitud no incluye un encabezado deRange
o si el servidor no admite la operación de subintervalo.
El servidor DEBERÍA proporcionar respuesta 206 (contenido parcial), si el encabezado If-Range
coincide con la etiqueta de entidad actual para la entidad. De lo contrario, el servidor DEBERÍA devolver la entidad completa utilizando una respuesta 200 (OK).
Resultados indefinidos
Tener la siguiente combinación de encabezados conduce a un resultado indefinido:
- If-Modified-Since y If-Match
- If-Modified-Since y If-Unmodified-Since
- If-None-Match y If-Match
- If-None-Match y If-Unmodified-Since
Estas reglas se han descompuesto de las siguientes (se pueden encontrar en RFC2616 ):
- If-Match y (If-None-Match o If-Modified-Since)
- If-Modified-Since y (If-Match o If-Unmodified-Since)
- If-None-Match y (If-Match o If-Unmodified-Since)
- If-Unmodified-Since y (If-None-Match o If-Modified-Since)
Actualmente estoy creando un script PHP que responderá a HTTP "304 Not Modified" cuando sea necesario.
(Ver pregunta # 2086712 por lo que hago hasta ahora).
Actualmente respondo a lo siguiente:
- If-Modified-Since
- If-None-Match
Pero descubrí que 3 encabezados más pueden desencadenar un "GET condicional" (Ver http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.3 ):
- If-Match
- Si-Sin modificaciones-Desde
- If-Range
Los dos últimos parecen irrevelables para mi sistema de almacenamiento en caché (parece que se usarán al reanudar descargas "grandes") pero no he encontrado si "If-Match" podría ser útil en mi sistema.
¿Se utiliza "If-Match" en los proxies o en el navegador web para el contenido de la página "normal"? ¿Cómo "If-Match" es diferente a "If-None-Match"?
¿Debería apoyar esos 3 o solo algunos de ellos? Cualquier ayuda bienvenida!