RFC9110 - GzipHandler must produce Content-Location header on 304 response?

[joakime]

Jetty version(s)
Jetty 10+

Description
When working Issue #8905 about the Vary header in 304 responses, I noticed a curious header called Content-Location.

See RFC9110, and the Content-Location header - https://www.rfc-editor.org/rfc/rfc9110#field.content-location

Seems that when the GzipHandler produces a 304 (Not Modified) it MUST produce a Content-Location response header?
https://www.rfc-editor.org/rfc/rfc9110#name-304-not-modified

The server generating a 304 response MUST generate any of the following header fields that would have been sent in a 200 (OK) response to the same request:

Content-Location, Date, ETag, and Vary
Cache-Control and Expires (see [CACHING])

[joakime]

@gregw what do you think?

[gregw]

I think that we never generate a Content-Location header with any of our 200 responses, so we therefore meet the criteria of "MUST generate any of the following header fields that would have been sent in a 200 (OK) response". I.e since we don't generate in a 200, then we don't need to generate in a 304.

Besides, the GzipHandler never produces a 304, it only reacts if something else produces a 304.

[joakime]

Could this be a possible requirement for ResourceService then? that produces a 304.

[gregw]

Let's make this for consideration as part of #8769 otherwise leave GzipHandler as is for now.