* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Ticket #345 (closed design: fixed)

Opened 3 years ago

Last modified 16 months ago

Required headers on 304 and 206

Reported by: mnot@pobox.com Owned by: draft-ietf-httpbis-p4-conditional@tools.ietf.org
Priority: normal Milestone: 20
Component: p4-conditional Severity: In WG Last Call
Keywords: Cc:
Origin:

Description

In [860], the list of required headers on 304 and 206 responses was changed.

I implemented this requirement a little while ago in RED <https://github.com/mnot/redbot/commit/2d088f1cee3c57317205a58424e259f590ab449e>, and subsequently got asked about where it came from <http://webmasters.stackexchange.com/questions/25520/should-304-not-modified-responses-include-the-last-modified-header>.

AFAICT this change happened in p4 -11 (similar changes were in p5 for 206), but there wasn't an associated issue, and it makes existing implementations (including Apache) non-conformant. E.g.,<http://redbot.org/?uri=http%3A%2F%2Fwww.apache.org%2F>.

Change History

comment:1 Changed 3 years ago by fielding@gbiv.com

Apache is currently conforming to the requirement in 2616 that nothing other than the listed fields be sent. When I rewrote the contorted section in [860], I could not think of any reason for Last-Modified to be excluded from the list, but we can revert that addition -- the only case it effects is if the ETag remains the same (leading to the 304) even though the Last-Modified has changed.

comment:2 Changed 3 years ago by fielding@gbiv.com

  • Status changed from new to closed
  • Resolution set to incorporated

comment:3 Changed 3 years ago by julian.reschke@gmx.de

See [1545]

comment:4 Changed 3 years ago by mnot@pobox.com

  • Status changed from closed to reopened
  • Resolution incorporated deleted

Still present in p5 (206).

comment:5 Changed 3 years ago by mnot@pobox.com

  • Milestone changed from unassigned to 20

comment:6 Changed 3 years ago by ylafon@w3.org

  • Status changed from reopened to closed
  • Resolution set to fixed

Fixed in [1658]:

Reverted partially [860], fixes #345

comment:7 Changed 3 years ago by ylafon@w3.org

  • Status changed from closed to reopened
  • Resolution fixed deleted

svn comment triggered closing with the wrong resolution...

comment:8 Changed 3 years ago by ylafon@w3.org

  • Status changed from reopened to closed
  • Resolution set to incorporated

comment:9 Changed 3 years ago by mnot@pobox.com

  • Status changed from closed to reopened
  • Resolution incorporated deleted

Current text repeats itself ("and/or Vary"):

Cache-Control, ETag, Expires, Content-Location and/or Vary, and/or Vary, if the header field would have been sent in a 200 response to the same request

comment:10 Changed 3 years ago by ylafon@w3.org

From [1659]:

See #345 (rule of thumb, editing with only one hand lead to trouble of vision)

comment:11 Changed 2 years ago by mnot@pobox.com

  • Status changed from reopened to closed
  • Resolution set to incorporated

comment:12 Changed 2 years ago by mnot@pobox.com

  • Status changed from closed to reopened
  • Resolution incorporated deleted

comment:13 Changed 2 years ago by mnot@pobox.com

  • Status changed from reopened to closed
  • Resolution set to fixed

comment:14 Changed 19 months ago by mnot@pobox.com

  • Status changed from closed to reopened
  • Resolution fixed deleted
  • Severity changed from Active WG Document to In WG Last Call
  • Milestone changed from 20 to unassigned

In 2616, Expires, Cache-Control and Vary are only required in a 304 if their values differ; after this change, they're required all the time.

Was this an intentional change, and if so, why?

Spurred by:

http://www.w3.org/mid/516D5C36.4040003@andrew.cmu.edu

comment:15 Changed 16 months ago by fielding@gbiv.com

  • Status changed from reopened to closed
  • Resolution set to fixed
  • Milestone changed from unassigned to 20

The change was intentional. A server has no means to determine what values a cache might already have for those fields, so saying that they only be sent when they differ is complete nonsense (or a hidden requirement that servers remember all past metadata of a resource for all time). Hence, they are now required if they would have been sent in a 200, which is really what 2616 intended to say.

Restoring this ticket's status to closed and fixed, to reflect the original change.

Note: See TracTickets for help on using tickets.