The Key HTTP Response Header Field
draft-fielding-http-key-03
| Document | Type | Replaced Internet-Draft (candidate for httpbis WG) | |
|---|---|---|---|
| Last updated | 2015-10-14 (latest revision 2015-09-23) | ||
| Replaced by | draft-ietf-httpbis-key | ||
| Stream | IETF | ||
| Intended RFC status | (None) | ||
| Formats |
Expired & archived
plain text
pdf
html
bibtex
|
||
| Stream | WG state | Call For Adoption By WG Issued | |
| Document shepherd | No shepherd assigned | ||
| IESG | IESG state | Replaced by draft-ietf-httpbis-key | |
| Consensus Boilerplate | Unknown | ||
| Telechat date | |||
| Responsible AD | (None) | ||
| Send notices to | (None) | ||
https://www.ietf.org/archive/id/draft-fielding-http-key-03.txt
Abstract
The 'Key' header field for HTTP responses allows an origin server to describe the secondary cache key ([RFC7234], section 4.1) for a resource, by conveying what is effectively a short algorithm that can be used upon later requests to determine if a stored response is reusable for a given request. Key has the advantage of avoiding an additional round trip for validation whenever a new request differs slightly, but not significantly, from prior requests. Key also informs user agents of the request characteristics that might result in different content, which can be useful if the user agent is not sending request header fields in order to reduce the risk of fingerprinting.
Authors
Roy Fielding
(fielding@gbiv.com)
Mark Nottingham
(mnot@mnot.net)
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)