W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2012

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

From: Zhong Yu <zhong.j.yu@gmail.com>
Date: Wed, 21 Mar 2012 21:38:05 -0500
Message-ID: <CACuKZqFF5xuii-89Qaa-PsOkLizre7NLYwz-kBSXP4kaxsKBzg@mail.gmail.com>
To: Mark Nottingham <mnot@mnot.net>
Cc: "Roy T. Fielding" <fielding@gbiv.com>, HTTP Working Group <ietf-http-wg@w3.org>
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

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/
>
>
>
>
>
Received on Thursday, 22 March 2012 02:38:33 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:57 GMT