- From: Glenn Strauss <gs-lists-ietf-http-wg@gluelogic.com>
- Date: Sat, 1 Feb 2025 00:27:55 -0500
- To: Mike Kistler <mikekistler@microsoft.com>
- Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
On Fri, Jan 31, 2025 at 03:58:01PM +0000, Mike Kistler wrote: > > Start out with the base assumption that “unsupported” means unrecognized, for which there is the general requirement that recipients ignore unrecognized fields. > > Is this true just for the conditional fields or for all fields? For example, can a recipient decide that it does not recognize "content-type" or "accept" fields and ignore these? "can a recipient decide that it does not recognize ..." That phrasing reads awkwardly. A recipient not might look for these headers, and subsequently not take any action based on these headers for which it did not look. It really is as simple as that. Is the recipient allowed to do that? Yes, for a server compliant with the original HTTP/1.1 specification https://www.rfc-editor.org/rfc/rfc2616 for anything for which the RFC does not define MUST or MUST NOT behavior. Accept: https://www.rfc-editor.org/rfc/rfc2616#section-14.1 Content-Type: https://www.rfc-editor.org/rfc/rfc2616#section-14.17 Do you see any MUST or MUST NOT requirement? A server might ignore the client request body, though if a server does process the request body, then the server ought to understand it, suggesting, but not requiring, that the server understand the Content-Type. However, the server might sniff the media-type from the request body, or might save the request body without understanding the Content-Type and without any other processing. As for Accept, these are hints to the server and if the server only provides a single type for a resource, the code path on the server delivering that resource might not bother to check for Accept type negotiation. The server is still compliant with the HTTP/1.1 specification, though could more fully implement the pedantic check in that case. > And when a client receives a 200 response from a request that included a conditional header, do they have any assurance that the conditional header was respected? It seems not. In the positive case, yes. In the negative case, no. However, the server behavior for requests using conditional headers is intended to be sane in the case where the conditional header is not recognized or not processed for the request. If a server receives a conditional header and recognizes the conditional header *AND* if the resource matches the conditional header in a positive fashion, THEN the server response might indicate to the client that the conditional header was processed by the server. For example, if the client sends If-Modified-Since, then the server might respond with 304 Not Modified, indicating processing of the If-Modified-Since for the request for that specific resource. (Not all resources might support If-Modified-Since.) If the server responds 200 OK with a response body, then the client does not definitively know whether or not the server understands If-Modified-Since, even if the server includes a Last-Modified header in the response. Cheers, Glenn
Received on Saturday, 1 February 2025 05:28:03 UTC