Subject: Confusion in preconditions

From: Sebastien Lambla <[email-masked]>
Date: Wed, 1 Feb 2012 02:35:34 +0000

Hi,

I'm confused by the text in p4-conditional.

2.4.

 An HTTP/1.1 origin server, upon receiving a conditional request that
   includes both a Last-Modified date (e.g., in an If-Modified-Since or
   If-Unmodified-Since header field) and one or more entity-tags (e.g.,
   in an If-Match, If-None-Match, or If-Range header field) as cache
   validators, MUST NOT return a response status code of 304 (Not
   Modified) unless doing so is consistent with all of the conditional
   header fields in the request.

3.1, 3.2, 3.3, 3.4

The result of a request having both an If-Match header field and
   either an If-None-Match or an If-Modified-Since header fields is
   undefined by this specification.

I *think* the specification does define partially a behavior when multiple conditional headers are present in the scenario leading to a 304, or am I misunderstanding the definition?

---

From: Zhong Yu <[email-masked]>
Date: Wed, 1 Feb 2012 00:11:30 -0600

On Tue, Jan 31, 2012 at 8:35 PM, Sebastien Lambla <[email-masked]> wrote:
> I *think* the specification does define partially a behavior when multiple
> conditional headers are present in the scenario leading to a 304, or am I
> misunderstanding the definition?

I would say the spec lists some constraints, that must/should be
satisfied, even in "undefined" scenarios. You may say that's "partial
definition".

    The result of a request having both ... header fields
    is undefined by this specification.

These explicit "undefined" disclaimers sounds out-of-place, given the
general vague nature of the spec. It seems to be a cop-out: "don't
even ask me what if these headers co-exist; I don't want to talk about
it"

One must wonder, the problem of conditionals appears to be very easy.
We can have a simple model and a simple procedure, that succinctly and
precisely defines behaviors in any scenario.

Why does the spec instead "beat around the bush", going very
roundabout ways, only setting some constraints on some scenarios? Are
readers supposed to solve the riddles to learn the underlying model?

Maybe it's because many implementations existed before the spec, and
the spec had to be careful not to brand them as invalid. The spec was
content to merely record generally accepted practice in certain
scenarios, and to forbid generally unexpected/unaccepted behavior in
other scenarios. It did not know a simple model that approximates most
established implementations in all scenarios.

Given the boundary constraints listed in the spec, one may assume many
variants of implementations can be compliant. That may not be the
case. Maybe the constraints are contradictory. Maybe the constraints
are so tight that it allows only a few variants, and it'd be simpler
if the spec directly spells out the few variants instead of the
numerous constraints. It's hard to tell. We need someone who can read
through it without passing out.

Maybe we shouldn't worry too much. Implementations pretty much
anticipate only simple/common scenarios; that's ok because all
participants are similarly simple minded. If we request

    GET / HTTP/1.1
    Host: www.google.com
    If-Match: random-fake-etag

according to the spec the server MUST respond with 412 . But most
servers will (unconsciously) ignore the If-Match and return 200,
because no real world client would send such request in the first
place.

Zhong Yu

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 01 Feb 2012 20:39:36 +1300

On 01.02.2012 19:11, Zhong Yu wrote:
> On Tue, Jan 31, 2012 at 8:35 PM, Sebastien Lambla wrote:

I am pushing to have the conditionals interpreted as a AND condition 
between all present conditionals.

  if anything needs a special status response -> do that
  if any of the conditions is invalid => 412 status
  if ( (If-Match x) AND (If-None-Match y or z) AND (if-modified-since T) 
AND ... ) => 2xx status
  otherwise 304 status

This *seems* to cover all the use cases and provide a useful consistent 
interpretation for which of the "undefined" cases might be useful or 
senseless as well.

I'm still waiting for someone in this WG with more experience to 
produce a use-case where that rule-of-thumb actually breaks something.

AYJ