- From: Zhong Yu <zhong.j.yu@gmail.com>
- Date: Wed, 21 Mar 2012 21:38:05 -0500
- 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 UTC