The Key HTTP Response Header Field
draft-fielding-http-key-02
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
Expired & archived
|
|
|---|---|---|---|
| Authors | Roy T. Fielding , Mark Nottingham | ||
| Last updated | 2013-08-22 (Latest revision 2013-02-18) | ||
| Replaced by | draft-ietf-httpbis-key | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | Expired | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
The 'Key' header field for HTTP responses allows an origin server to describe the cache key for a negotiated response: a short algorithm that can be used upon later requests to determine if the same response is reusable. 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 Accept* fields in order to reduce the risk of fingerprinting.
Authors
Roy T. Fielding
Mark Nottingham
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)