Subject: WGLC Issue for p4: Optionality of Conditional Request Support

From: Mark Nottingham <[email-masked]>
Date: Fri, 16 Mar 2012 19:53:43 +1100

Is p4 optional or not (for servers, clients, etc.)? I think it is, and so it should be explicitly marked as such.

E.g., 

* 2.2.1 Generation - "Origin servers SHOULD send Last-Modified..." -- is this really a SHOULD, or should we just encourage them to? If p4 is optional, I don't think we can impose this as a SHOULD.

* 2.3.1 Generation - "Origin servers SHOULD send ETag..." -- is this really a SHOULD, or should we just encourage them to? If p4 is optional, I don't think we can impose this as a SHOULD.

* 2.4 Rules... - there are many requirements for servers and clients here; I think they need to be downgraded if p4 is indeed optional.

--
Mark Nottingham   http://www.mnot.net/

---

From: "Roy T. Fielding" <[email-masked]>
Date: Fri, 16 Mar 2012 15:16:48 -0700

> Is p4 optional or not (for servers, clients, etc.)? I think it is, and so it should be explicitly marked as such.

Nope, conditional requests have always been a SHOULD implement
because of the benefits to the rest of Internet.

....Roy

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 19 Mar 2012 10:24:45 +1100

> because of the benefits to the rest of Internet.

My .02 - The caching benefits are nice, but whether or not it's supported doesn't affect interop; it's a "moral" SHOULD. 

WRT pre-conditions on unsafe requests, most servers IME don't consistently honour If-Match or If-Unmodified-Since on POST, PUT, etc. requests (especially since POST is often handled by CGI). While we might say that it's REQUIRED or SHOULD or whatever, in real life it's treated as an optional add-on feature.

I think we should call it such; implying that it's required to be supported by servers leads clients to believe that they can count on it. We can encourage its implementation, highlight the dangers of not supporting it, etc., of course.

--
Mark Nottingham
http://www.mnot.net/

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 19 Mar 2012 22:28:34 +1100

In If-Match:

> If none of the entity-tags match, or if "*" is given and no current representation exists, the server must not perform the requested method. Instead, the server must respond with the 412 (Precondition Failed) status code.

BTW, I think those mentions of "server" in the quoted bit above really need to be "origin server."

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 22 Mar 2012 10:55:06 +1100

Now <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/350>.

---

From: Zhong Yu <[email-masked]>
Date: Wed, 21 Mar 2012 21:38:05 -0500

Mark,

If preconditions on conditional unsafe requests can be *officially*
ignored, a client MUST not send such requests to a server, because the
semantics are fatally ambiguous, unless the client knows out-of-band
that the server does support such requests properly.

You are arguing that this is not much different from today's situation
where most servers don't support such requests properly anyway
therefore clients cannot reliably issue these requests; that being the
reality, why not spare the servers the guilt?

But why so nice to servers? What's the harm if we continue labeling
these servers as non compliant?

And this discussion is only relevant if a server is committed to
receive requests from the open wild; in that case the server is
expected to be very well built; if it doesn't properly handle "PUT +
If-Match", it should be considered a bug.

However in most of today's applications, servers and clients are in
cahoots. A server can legitimately expect the forms of requests it'll
receive from clients.

For example, a server returns to clients HTML pages with javascripts
sending certain PUT requests back to the server. The server will only
honor these PUT requests generated by these scripts; it's not
advertise as an open API. If a "strange" client adds an unexpected
header, say If-Match, the server is under no obligation whatsoever to
honor it; it can legitimately ignore the header.

The question is, can we label this server as "non compliant"? That
seems too harsh. We shouldn't force a server to waste resources to
meticulously process requests it shouldn't receive in the first place.

This is not limited to conditional requests, it applies to all kinds
of requests. Essentially, a server can "filter" incoming requests into
expected requests(within reason). It think we should have the
understanding that a server is allowed to do that, even though it is
technically non compliant.

Zhong Yu

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 26 Mar 2012 11:25:35 +0200

> these servers as non compliant?

Thinking about this more, I'm inclined to agree. 

The case that I'm concerned about is where a resource that's handled by something like CGI, PHP, etc. doesn't support If-Match. However, if they're bothering to generate ETags, they really should handle this correctly. 

Discussing this with Roy here, the underlying requirements are not for interoperability, they're social requirements -- i.e., if servers don't support caching, it places a greater burden on the network. As such, I think they're appropriate, they just need to be explained. I'll propose a *small* amount of prose to close this ticket.

Cheers,

--
Mark Nottingham
http://www.mnot.net/