Re: Response for unsupported conditional request

> On Jan 29, 2025, at 4:01 PM, Mark Nottingham <mnot@mnot.net> wrote:
> 
> Hmm. I'm trying to page in the discussions we had around this section, but it seems like there's a contradiction here.

Start out with the base assumption that “unsupported” means unrecognized, for which there is the general requirement that recipients ignore unrecognized fields. How would a recipient know that a field is a conditional if they don’t recognize it?

If the recipient does recognize the field as a conditional, that means it can know the definition and follow the HTTP requirements associated with its processing. The requirements are based on features, many of which might be optional for the server or for the target resource. Optional means ignore the field if unsupported.

If a conditional header field is recognized and applicable to a feature that the server intends to support for the target resource, then the protocol sometimes requires a specific response under certain conditions. Obey or be non-compliant. Nothing in the spec enforces compliance with the protocol. Stuff just doesn’t interop as well.

>> 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?

No. There are requirements on what fields must be supported, what to do when that support is communicated, and what can be safely ignored. When there is no requirement, it means that a specific response code is not required. Whatever you send will communicate the status as defined by that code.

If the choice matters for the target resource, support (recognize and implement) the header field. Specific responses are defined to communicate specific resource state, but in general any status code might be sent in response to any request: choose what is most important to communicate to the client.

….Roy

Received on Thursday, 30 January 2025 17:36:12 UTC