- From: Mark Nottingham <mnot@mnot.net>
- Date: Thu, 30 Jan 2025 11:01:17 +1100
- To: "Julian F. Reschke" <julian.reschke@gmx.de>
- Cc: ietf-http-wg@w3.org
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). > Extensibility of preconditions is only possible when the precondition can be safely ignored if unknown (like If-Modified-Since) This latter statement in particular implies that precondition headers have a potential property of "safety ignored if unknown" that isn't discussed further. Some of them do detail situations where the field can be ignored, for example If-Modified-Since says: > A recipient MUST ignore the If-Modified-Since header field if the resource does not have a modification date available. However, that's not "unknown" (presumably, to the server doing the evaluating). The only related issues I found from bis were: https://github.com/httpwg/httpbis-issues/issues/350 https://github.com/httpwg/httpbis-issues/issues/479 Cheers, > On 30 Jan 2025, at 3:05 am, Julian Reschke <julian.reschke@gmx.de> wrote: > > Am 27.01.2025 um 22:47 schrieb Mike Kistler: >> Is there a required or recommended response that a server should give if >> it receives a request with a conditional header (If-Match, If-No-Match, >> If-Modified, If-Unmodified) that it does not support? >> >> I've read the descriptions for the required processing of these headers >> in RFC 9110 and it seems clear that servers are obligated to support >> them -- but in my experience many do not. So in the case that server >> does not support conditional requests, it seems like it should respond >> with an error if it receives a request with a conditional header. Should >> the response be a 501 (Not Implemented)? Could it be a 400 (Bad >> Request)? Something else? I looked for guidance on this in RFC 9110 but >> could not find it, so apologies if I just overlooked it. > > It needs to be a 5xx - because it's a server problem. > > 501 sounds reasonable to me. > > Best regardsm Julian > -- Mark Nottingham https://www.mnot.net/
Received on Thursday, 30 January 2025 00:01:28 UTC