Opened 10 years ago

Closed 10 years ago

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

proposal: change to

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

comment:3 Changed 10 years ago by mnot@…

  • Milestone changed from unassigned to 21

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

From [1814]:

fix description of handling invalid dates (see #375)

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

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

comment:6 Changed 10 years ago by mnot@…

  • Resolution incorporated deleted
  • Status changed from closed to reopened

comment:7 Changed 10 years ago by mnot@…

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

comment:8 Changed 10 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.