Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unknown preconditions aren't safe #715

Closed
martinthomson opened this issue Jan 29, 2021 · 3 comments · Fixed by #817
Closed

Unknown preconditions aren't safe #715

martinthomson opened this issue Jan 29, 2021 · 3 comments · Fixed by #817

Comments

@martinthomson
Copy link
Contributor

Section 13 implies that a precondition failure is a good safe mode. However, a precondition that isn't recognized by a server will not share this property.

Regardless, if the mapping is inconsistent and the server is unable to select the appropriate representation, then no harm will result when the precondition evaluates to false.

A server that does not recognize a header as a precondition will ignore it and likely proceed with handling the request even if the precondition expressed should have failed.

Indeed, the same is true if a server ignores preconditions, though the specification effectively mandates that they be supported.

Section 13.2.2 is the only text I could find on defining new preconditions.

(One thing I really want to avoid is server's applying special heuristics to headers that start with If-, because that is one of many poor outcomes if this is left.)

@royfielding
Copy link
Member

royfielding commented Jan 31, 2021

There is also the example in the section above that

Conditional request header fields that are defined by extensions to HTTP might place conditions on all recipients, on the state of the target resource in general, or on a group of resources. 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 ([RFC4918], Section 10.4).

I suppose we could make a new section on precondition extensions, but they aren't a separate category (like If*). For example, my precondition proposal for 1.1 was an all-inclusive Unless that enclosed a logic bag (structured field value). Note that they have always depended on compliance-when-implemented, since I added the first (If-Modified-Since) in early 1994.

@royfielding royfielding self-assigned this Jan 31, 2021
@mnot mnot added the discuss label Feb 5, 2021
@mnot mnot removed the discuss label Feb 15, 2021
@mnot
Copy link
Member

mnot commented Mar 22, 2021

Does this need to be in this specification?

@martinthomson
Copy link
Contributor Author

I think we're almost in the extension territory (I like the idea of a header field that lists the applicable precondition fields). As far as this specification goes, simply noting that new preconditions won't share properties of the core preconditions, in particular the expectation that it is understood by servers.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging a pull request may close this issue.

4 participants