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

Ticket #241 (closed design: fixed)

Opened 4 years ago

Last modified 2 years ago

Need to clarify eval order/interaction of conditional headers

Reported by: julian.reschke@gmx.de Owned by:
Priority: normal Milestone: 20
Component: p4-conditional Severity: In WG Last Call
Keywords: Cc:
Origin: http:///www.w3.org/mid/20100824020136.fe476a9c.eric@bisonsystems.net

Description

Section 1 currently states:

"...In particular, the sections on resource metadata will be discussed first and then followed by each conditional request-header, concluding with a definition of precedence and the expectation of ordering strong validator checks before weak validator checks..."

See also Eric's feedback in <http://lists.w3.org/Archives/Public/ietf-http-wg/2010JulSep/0244.html>

Change History

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

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

  • Severity changed from Candidate WG Document to Active WG Document

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

  • Severity changed from Active WG Document to In WG Last Call

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

Here is the order that Apache httpd uses. When I wrote it, I realized that there is only one logical order for preconditions because ETag is presumed to be more accurate than LM. Likewise, the exact match fields (If-Match and If-Unmodified-Since) have priority over the weaker conditions in the unlikely event that they are ever used together in the same request.


Check for conditional requests — note that we only want to do this if we are successful so far and we are not processing a subrequest or an ErrorDocument?.

The order of the checks is important, since ETag checks are supposed to be more accurate than checks relative to the modification time. However, not all documents are guaranteed to have ETags, and some might have Last-Modified values w/o ETags, so this gets a little complicated.

If an If-Match request-header field was given AND the field value is not "*" (meaning match anything) AND if our strong ETag does not match any entity tag in that field, respond with a status of 412 (Precondition Failed).

Else if a valid If-Unmodified-Since request-header field was given AND the requested resource has been modified since the time specified in this field, then the server MUST respond with a status of 412 (Precondition Failed).

If an If-None-Match request-header field was given AND the field value is "*" (meaning match anything) OR our ETag matches any of the entity tags in that field, fail.

If the request method was GET or HEAD, failure means the server SHOULD respond with a 304 (Not Modified) response. For all other request methods, failure means the server MUST respond with a status of 412 (Precondition Failed).

GET or HEAD allow weak etag comparison, all other methods require strong comparison. We can only use weak if it's not a range request.

If a valid If-Modified-Since request-header field was given AND it is a GET or HEAD request AND the requested resource has not been modified since the time specified in this field, then the server MUST respond with a status of 304 (Not Modified). A date later than the server's current request time is invalid.

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

  • Type changed from editorial to design

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

From [1799]:

p4: Add a section for precedence of conditional request fields and remove

paragraphs that say it isn't defined. Addresses #241 Clarify that If-Modified-Since only applies to GET and HEAD. Addresses #371

also generated HTML

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

  • Status changed from new to closed
  • Resolution set to incorporated
  • Milestone changed from unassigned to 20

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

  • Status changed from closed to reopened
  • Resolution incorporated deleted

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

  • Status changed from reopened to closed
  • Resolution set to fixed
Note: See TracTickets for help on using tickets.