[
https://issues.apache.org/jira/browse/TS-4506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15354531#comment-15354531
]
ASF GitHub Bot commented on TS-4506:
------------------------------------
Github user mlibbey commented on the issue:
https://github.com/apache/trafficserver/pull/749
The RFC portion didn't mandate removing Last-Modified. ("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've seen one case where
others were expecting it to be their regardless of the ETag (because another
large commercial CDN does it that way).
> Last-Modified and Expires headers are removed on 304 responses when they
> shouldn't
> ----------------------------------------------------------------------------------
>
> Key: TS-4506
> URL: https://issues.apache.org/jira/browse/TS-4506
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
> Reporter: Leif Hedstrom
> Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
>
> Right now, when ATS generates a 304 response (Not Modified), we always remove
> the Last-Modified header. Reading the RFC, we should only remove the
> Last-Modified header if there is an ETag header. This is a simple fix, and we
> should just do it IMO.
> It also always removes the Expires headers, which we are not supposed to
> touch. Now, we do overwrite the Cc: header, so maybe we should remove that
> too ?
> From https://tools.ietf.org/html/rfc7232#page-18:
> {code}
> 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: Cache-Control, Content-Location, Date,
> ETag, Expires, and Vary.
> 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).
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
