No validator requirement in 2xx response for conditional update

[lashchev]

RFC7232 in https://tools.ietf.org/html/rfc7232#section-3.1 has the following clause:

In the latter case, the origin server MUST NOT send a validator header field in the response unless it can verify that the request is a duplicate of an immediately prior change made by the same user agent

It doesn't really explain what security or performance considerations are leading to such a requirement, but it calls for a lot of infrastructure and design work to implement it because that logic can be implemented only if the server is stateful. The stateless server cannot comply with such a requirement.

See related mail list thread: https://lists.w3.org/Archives/Public/ietf-http-wg/2018OctDec/0051.html

Either RFC should explain why such logic MUST be implemented or relax "MUST" into "SHOULD" in that clause or remove that clause completely.

[lashchev]

Should I submit an errata proposing to remove the following clause from RFC 7232, section 3.1:
" In the latter case, the origin server
MUST NOT send a validator header field in the response unless it can
verify that the request is a duplicate of an immediately prior change
made by the same user agent"
It seems like nobody can recall/explain why this clause is there.

[royfielding]

I finally found the original commit 303b82b

[royfielding]

And the discussion motivating the change is under trac 455. Certainly the intent was to remove the constraint that an error be sent when a duplicate request is made, so the extra limitations were to reduce edge cases.

[royfielding]

It is not an errata. This is the right place to discuss it and either find a better wording or strike the text.

[lashchev]

Thanks, @royfielding for finding the original commit and your response!

Sending 2xx response for repeating requests makes total sense. My issue is about a sub-condition of 2xx response that is stated in the RFC7232. In the original commit that you referenced that sub-condition is stated as:

In the latter case, the origin server MUST NOT send a 204 (No Content) status code unless it can verify that the request is a duplicate of an immediately prior change made by the same user agent.

I think I understand the original recommendation not to send 204 back. It would be better to replace MUST NOT with SHOULD NOT there though.

But in RFC7232 that sub-condition clause is changed to:

In the latter case, the origin server MUST NOT send a validator header field in the response unless it can verify that the request is a duplicate of an immediately prior change made by the same user agent

The reason of not sending ETag with 2xx back is not explained in RFC7232 and nobody can remember why it is there or explain this requirement. Complying with this requires dev effort and extra infra since we would need to track immediate previous requests from each agent. Our API servers are light-weight and stateless so this is a huge requirement for us.

Instead, we would prefer a way simpler approach of always sending ETag back along with 2xx responses, but we need to comply with RFC7232 thus this discussion.

So, the proposal is to do one of the following

1. (preferred) Remove the following clause from RFC7232:

"In the latter case, the origin server MUST NOT send a validator header field in the response unless it can verify that the request is a duplicate of an immediately prior change made by the same user agent

2. (If aforementioned clause is kept) Explain the reason of not sending ETag in that sub-condition
3. (at least) Change MUST NOT to SHOULD NOT in that clause.

[royfielding]

These requirements were motivated by a tiny edge case related to protecting partial updates after two clients simultaneously try a PUT. However, I can't remember if it was when one succeeds and one fails, or one or both responses are lost and they try again, or something like that, nor can I remember what difference was made by not sending ETag.

Hence, I intend to remove the requirement as being too obscure to implement in a testable way.