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

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/

Received on Monday, 26 March 2012 09:26:01 UTC