Re: [EXTERNAL] Re: Response for unsupported conditional request

On Tue, Feb 04, 2025 at 01:53:56PM +0000, Mike Kistler wrote:
> 
> > Imagine that you had a new condition field called "If-YouFeelLikeIt".  There is no expectation that every resource on every
> > server supports that, so any MUST-level statement you make about processing that field comes with an implicit "if you
> > support and implement this field" attached.  Most servers and resources won't support this field and so clients cannot
> > expect that the condition would be followed.
> 
> Well okay, but Section 5.1 of RFC 9110 says:
> 
> New fields can be introduced without changing the protocol version if their defined semantics allow them to be safely ignored by recipients that do not recognize them; see Section 16.3.
> 
> So is the rationale here that If-Match is "safely ignored by recipients"? And if that's the case, then why doesn't the RFC state this explicitly?

Multiple reasons have already been given.  I'll repeat one:

This is the nature of a heterogeneous internet with clients and servers
of widely varying ages, protocol support, and simplicity/complexity.


A resource served by a server might not generate Last-Modified or ETag.

If a server does not generate an ETag for a resource, then the server
may not apply If-Match and might ignore If-Match sent by the client.

Even if the server supports If-Match on other resources, the server
may ignore If-Match on resources for which the server does not produce
an ETag.  Or, a pedantic server could choose to reject a request for
If-Match on a resource without an ETag, returning 412 Precondition
Failed.


Try to think of it this way:

A client makes a *request* to a server, not a *command*.
It is called an HTTP request, not an HTTP command.
Conditional HTTP request headers may be part of the *request*.

I think you may have a misguided assumption that all RFCs are
somehow strictly enforced everywhere.  They are not.

Cheers, Glenn

Received on Tuesday, 4 February 2025 17:04:21 UTC