Re: Using conditional requests with 100 Continue

> On Oct 21, 2019, at 3:41 PM, Austin Wright <aaa@bzfx.net> wrote:
> 
> Hello,
> 
> I’m reading through RFC 7231 and RFC 7232 to implement an HTTP server that supports a PUT method on a resource, with 100 Continue and 412 Precondition Failed responses; and I am wondering why 412 must be tested last, after all other errors.
> 
> The uploaded document must conform to certain media type and validation requirements, perhaps responding with an error like 400 (Bad Request) or 422 (Unprocessable Entity) if the upload is not well-formed. Suppose I issue a request with:
> 
> Expect: 100-continue
> If-Match: “etag”
> 
> In this case, it seems to me the server should issue a 412 Precondition Failed if the resource has been changed, and that I shouldn’t have to upload the entire document just to find out that it has been changed. Yet, RFC 7232 HTTP Conditional Requests says:
> 
> > A server MUST ignore all received preconditions if its response to the same request without those conditions would have been a status code other than a 2xx (Successful) or 412 (Precondition Failed). In other words, redirects and failures take precedence over the evaluation of preconditions in conditional requests.
> 
> This suggests that I must validate the document in its entirety if I’m going to return a status like 422, before testing the precondition, even if the upload is very long.
> 
> (1) Is there a particular reason that the precondition test must be tested after all other 4xx (even 5xx) errors?

The simple answer is that 422 did not exist at the time the requirement was written.
The more complex answer is that the requirement should be restated to talk only about
errors that are discovered before the body is processed.

If you can, please add an issue for that to "https://github.com/httpwg/http-core/issues <https://github.com/httpwg/http-core/issues>"
(if not, let me know and I will add one).

> Now, I imagine this requirement might have the effect of reducing some race conditions, but even then it would not completely eliminate race conditions, without a way of locking the database/filesystem record for writing.
> 
> (2) Are there clients in the wild that would be broken if the precondition test happened earlier? i.e. are there any clients that would incorrectly assume the upload is well-formed if they received a 412 error instead of a 400, 415, and/or 422?
> 
> (3) For 100-continue and performance purposes, can this limitation be relaxed so it’s the last thing tested before errors relating to the request entity-body?

Yes.

....Roy