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

Ticket #375 (closed design: fixed)

Opened 2 years ago

Last modified 18 months ago

"Most Conservative"

Reported by: mnot@pobox.com Owned by:
Priority: normal Milestone: 21
Component: p6-cache Severity: In WG Last Call
Keywords: Cc:
Origin: http://stackoverflow.com/questions/11448772/most-conservative-conversion-to-gmt

Description

Section 19.3 "Tolerant Applications" of the HTTP 1.1 RFC (2616) says on the subject of parsing dates from HTTP client applications:

If an HTTP header incorrectly carries a date value with a time zone other than GMT, it MUST be converted into GMT using the most conservative possible conversion.

Two questions:

Does this mean that the server MUST convert a non-GMT date value to GMT? Or does it mean that if (optionally) it chooses to convert a non-GMT date value to GMT (rather than rejecting it) then it MUST use the most conservative possible conversion?

What is meant by "the most conservative possible conversion"?

Change History

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

In p6, this is:

If an HTTP header field incorrectly carries a date value with a time zone other than GMT, it must be converted into GMT using the most conservative possible conversion.

https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p6-cache.html#age.calculations

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

proposal: change to

Caches SHOULD consider dates with time zones other than "GMT" invalid.

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

  • Milestone changed from unassigned to 21

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

From [1814]:

fix description of handling invalid dates (see #375)

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

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

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

  • Status changed from closed to reopened
  • Resolution incorporated deleted

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

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

comment:8 Changed 18 months ago by fielding@gbiv.com

From [2082]:

Yet another attempt to explain HTTP-date, remove redundant requirements in sections that use HTTP-date, and correct some inconsistent requirements regarding time zones; related to #375 and [2077]

Note: See TracTickets for help on using tickets.