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

Have you had the chance to propose some prose for this ticket?  If not, 
was this approximately what you were thinking?

3.  Precondition Header Fields

This section defines the syntax and semantics of HTTP/1.1 header
fields for applying preconditions on requests.<new>If an origin server
supplies a Validator for a resources, the origin server MUST support the
corresponding conditionals.</new>

-----------------

I also had further concerns in this area.  I think the Conditional 
decision tree looks sort of like this:

Origin Server SHOULD generate Validators
--> UA MAY use Conditionals corresponding to the Validators
--> Origin Server MUST respect Conditionals

Since the UA only MAY use the conditionals, what should the Origin 
Server do if the UA doesn't supply a conditional?  For safe methods, 
it's no big deal.  However, for PUT & DELETE, I can see a case for UA 
MUST use the conditional.  So does this make sense?

3.1.  If-Match

The "If-Match" header field MAY be used to make a<new>safe</new>
request method conditional<new>and MUST be used to make an unsafe
request method conditional</new>  on the current existence or value
of an entity-tag for one or more representations of the target resource.

-----------------

Continuing the theme of Conditionals and method properties -- In last 
week's F2F discussion, there was some further discussion on the topic of 
conditional requests and PATCH.  Is the following assertion true?

Some Non-idempotent methods (e.g. PATCH) may be considered idempotent when the appropriate Conditional is applied (e.g. If-Match).

-----------------

Finally, how do Validators & Conditionals interact with POST?


Actually trying to contribute in a productive way ;-)
Ray

On 22/03/2012, at 3:38 AM, Zhong Yu wrote:

 > 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?

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,



 > 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
 >
 > On Sun, Mar 18, 2012 at 6:24 PM, Mark Nottingham <mnot@mnot.net> wrote:
 >>
 >> On 17/03/2012, at 9:16 AM, Roy T. Fielding wrote:
 >>
 >>> On Mar 16, 2012, at 1:53 AM, Mark Nottingham wrote:
 >>>
 >>>> 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.
 >>
 >>
 >> 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/
 >>

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