Combining HEAD responses

[mnot@…]

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.

1. This (i.e., the mechanics of how caches should combine responses) should be moved to p6
2. If possible, it should be part of the existing section on combining responses
3. It doesn't define how to combine other headers (p6 combining responses does; same algorithm?)
4. 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.

[mnot@…]

Looking into this, it's not valid to combine these.

• HEAD doesn't update a stored response, it replaces it (because it needs to contain all headers, not just some like 304).
• 304/204 handling of differing metadata is also likely to not be the same.

As such, only #1 really makes sense. Flipping to Editorial as a result.

[mnot@…]

Flipping back to Design; there are deeper issues lurking here.

[mnot@…]

From [1554]:

Move cache-specific HEAD language to p6; fully specify effects on cache. Addresses #227.

[julian.reschke@…]

From [1560]:

Note changes for [1554] (see #227)