You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.)
The text was updated successfully, but these errors were encountered:
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.
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.
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.
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.)The text was updated successfully, but these errors were encountered: