Ticket #227 (closed design: fixed)
Combining HEAD responses
|Reported by:||email@example.com||Owned by:||firstname.lastname@example.org|
|Component:||p6-cache||Severity:||Active WG Document|
Description (last modified by email@example.com) (diff)
p2 defines how HEAD responses affect caches:
The response to a HEAD request is cacheable and &MAY; be used to satisfy a subsequent HEAD request; see &caching;. It also &MAY; be used to update a previously cached representation from that resource; if the new field values indicate that the cached representation differs from the current representation (as would be indicated by a change in Content-Length, Content-MD5, ETag or Last-Modified), then the cache &MUST; treat the cache entry as stale.
- This (i.e., the mechanics of how caches should combine responses) should be moved to p6
- If possible, it should be part of the existing section on combining responses
- It doesn't define how to combine other headers (p6 combining responses does; same algorithm?)
- p6 combining responses doesn't talk about what to do to the cache state if the ETag, etc. differ (this does); should we incorporate this there? See also #117, somewhat related.
- Status changed from new to closed
- Resolution set to incorporated
- Milestone changed from unassigned to 19
- Status changed from closed to reopened
- Resolution incorporated deleted