Opened 7 years ago

Closed 6 years ago

Last modified 6 years ago

#375 closed design (fixed)

"Most Conservative"

Reported by: mnot@… Owned by:
Priority: normal Milestone: 21
Component: p6-cache Severity: In WG Last Call
Keywords: Cc:

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 (8)

comment:1 Changed 7 years ago by mnot@…

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 7 years ago by mnot@…

proposal: change to

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

comment:3 Changed 7 years ago by mnot@…

  • Milestone changed from unassigned to 21

comment:4 Changed 7 years ago by julian.reschke@…

From [1814]:

fix description of handling invalid dates (see #375)

comment:5 Changed 7 years ago by julian.reschke@…

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

comment:6 Changed 6 years ago by mnot@…

  • Resolution incorporated deleted
  • Status changed from closed to reopened

comment:7 Changed 6 years ago by mnot@…

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

comment:8 Changed 6 years ago by fielding@…

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.