Re: Response for unsupported conditional request

On Thu, Jan 30, 2025 at 06:17:07AM +0100, Julian Reschke wrote:
> On 30.01.2025 01:01, Mark Nottingham wrote:
> > Hmm. I'm trying to page in the discussions we had around this section, but it seems like there's a contradiction here.
> > 
> > Each of the preconditions defined in Section 13.1 have language like this:
> > 
> > > When an origin server receives a request that selects a representation and that request includes an If-Unmodified-Since header field without an If-Match header field, the origin server MUST evaluate the If-Unmodified-Since condition per Section 13.2 prior to performing the method.
> > 
> > 13.2.1 specifies a number of situations where the field can be ignored (e.g., by non-authoritative servers, by methods that don't select a representation), and then goes on to define the algorithm in 13.2.2. A server that does not support one of these fields would not execute at least part of the algorithm, violating the MUST.
> > 
> > However, 13.1 says two things that imply that entire precondition fields can be ignored in certain circumstances:
> > 
> > > For instance, the "If" header field in WebDAV can make a request conditional on various aspects of multiple resources, such as locks, if the recipient understands and implements that field ([WEBDAV], Section 10.4).
> 
> 
> Yes, that applies to conditional fields not defined in the base specs.
> So "If" in WebDAV, and future extensions.
> 
> This just follows from the rule that extensions can not add new
> requirements (their use would need to be negotiated, as it happens in
> WebDAV).

And likewise, any server that was developed before all the If-* were
invented remains compliant with the previous specs, so a client that
expects to be compatible with older versions must also expect that a
server doesn't know such header fields and will silently ignore them.

Cheers,
Willy

Received on Thursday, 30 January 2025 07:59:38 UTC