Turning that on its head. What use case needs including them?
Two reasons for not including them:
1) including headers on 304 means they *have* changed from the request
when testing/validating a text/html English language object modified
Would you expect the 304 response assertion that "yes this binary/gif
object with Greek text has not changed since 2012-04-11 12:00am" to
*ever* be valid?
For the 304 response to be valid those headers MUST be fixed constant
values with no possibility for corruption after the 200 response with
2) those headers are specifically defined as being related to the entity
attached to the response.
When sent on a 206 they indicate the 206 entity details. Not some
previous 200 responses.
It is reasonable to expect a range request which asked for example bytes
0-256 of a 4KB object without specifying which variant (gzip, identity,
etc) forms of the object is held already. The 206 entity might therefore
vary from one already held. This may not even matter for
display/use/caching purposes, but it is *very* important to know whether
merging of the ranges is or is not safe.