On Thu, Oct 4, 2018 at 7:20 PM William A Rowe Jr <wr...@rowe-clan.net> wrote: > > On Thu, Oct 4, 2018 at 12:09 PM Evgeny Kotkov <evgeny.kot...@visualsvn.com> > wrote: >> >> >> However, a more important question is whether there is an actual problem to >> solve. I see that ap_http_header_filter() features a whitelist of headers >> that are sent for 304 responses (http_filters.c:1428), and all headers such >> as Content-Encoding are filtered anyway. > > > AIUI Transfer-* headers should be filtered. Content-* headers must match > the specific ETag as if the response was 200, from my reading.
I'm reading the below as a "SHOULD NOT" for anything other than: Cache-Control, Content-Location, Date, ETag, Expires, and Vary. https://tools.ietf.org/html/rfc7232#section-4.1 : Since the goal of a 304 response is to minimize information transfer when the recipient already has one or more cached representations, a sender SHOULD NOT generate representation metadata other than the above listed fields unless said metadata exists for the purpose of guiding cache updates (e.g., Last-Modified might be useful if the response does not have an ETag field). I may be missing something but it seems to me that Content-Encoding shouldn't be set, "Vary: Accept-Encoding" is how we tell that content encoders (deflate, brotli...) are (or could be) in the place.
