[
https://issues.apache.org/jira/browse/TS-4506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15351645#comment-15351645
]
ASF GitHub Bot commented on TS-4506:
------------------------------------
GitHub user zwoop opened a pull request:
https://github.com/apache/trafficserver/pull/749
TS-4506 Should not remove Expires/Last-Modifed on 304 response
When generating a 304 page, we used to remove Expires and Last-Modified
always. This change makes sure we never touch Expires, and only remove
the Last-Modified header if the is an ETag in the response. This is per
the specs in
https://tools.ietf.org/html/rfc7232#page-18
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/zwoop/trafficserver TS-4506
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/trafficserver/pull/749.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #749
----
commit fb4f565f4437f9a18d6e8b049cbd45586e83b543
Author: Leif Hedstrom <zw...@apache.org>
Date: 2016-06-03T21:35:30Z
TS-4506 Should not remove Expires/Last-Modifed on 304 response
When generating a 304 page, we used to remove Expires and Last-Modified
always. This change makes sure we never touch Expires, and only remove
the Last-Modified header if the is an ETag in the response. This is per
the specs in
https://tools.ietf.org/html/rfc7232#page-18
----
> 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 no ETag header. This is a simple fix, and we
> should just do it IMO.
> It also always removes the Expires headers, which is outright wrong.
> 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)
