Re: No validator in 200 response for conditional update

On 7/11/18 11:35 AM, Vladimir Lashchev wrote:
> Thanks for your replies!
> 
> In general, since the spec says that server "MUST NOT" send an ETag in some case so in order to comply with the spec we must implement that logic and it does not matter if it is a corner case or if it may happen only once in our API. In reality it is actually not an edge case and happens quite often (up to single digit % of all requests in high volume concurrent scenarios).
> 

On a side note;

My understanding of the expected behaviour is that agents doing a lot of
repeats are broken in some way. Probably their author misunderstood that
412 is *not* an error.

A 4xx is just a notice from the server to the agent that the requested
change/fetch was not enacted. Not really errors in the way we tend to
think of errors in software.

So agents receiving back a 412 with ETag matching the one they tried to
set the resource to - should usually treat that as as much a success as
any 2xx they get. It is only when the 412 ETag is different that the
agent needs to figure whether to try again, and HTTP cannot help by
specifying anything about that decision.


> That's why I am trying to understand the reason because that clause calls for a lot of development.
> 
> Why "a lot" of development?
> Because the clause "... unless it can verify that the request is a duplicate of an immediately prior change made by the same user agent ..." requires us to persistently track previous requests from all clients which is a huge infra requirement for stateless API server farms (which is a typical design for servers with high performance requirements).

I fail to see how there is any difference in overhead for a large farm
than for a single server. All that needs to be tracked is what the
current ETag validator is and which agent made it exist. Usually those
would exist anyway in server state as author and version IDs.

In a large farm each stateless server may be tracking a different
version of the object (or not) with its own ETag + agent labels. That is
a given implied by them being stateless. The condition rules from the
request are applied by the individual server against its own object(s)
copy regardless of what other objects might be elsewhere or what might
have happened in old history for the relevant local object(s).

You _can_ do sharing of updates + info between the servers. But that is
up to the implementation and kind of disolves the claim of being stateless.

That said, I don't recall what was behind this RFC wording so am
watching to see what others reply to your specific questions.

HTH
Amos

Received on Wednesday, 7 November 2018 01:16:52 UTC