Re: Why should caches and intermediaries ignore If-Match?

> On Feb 26, 2017, at 3:49 PM, Mark Nottingham <mnot@mnot.net> wrote:
> 
> I think the best way to characterise the situation currently is that HTTP doesn't define any requirements for If-Match on non-origin servers; the only requirements in 7232 Section 3.1 apply to origin servers.
> 
> AFAIK current intermediaries ignore If-Match, so if you wanted to define some guidelines here, they'd need to be completely optional. E.g., "An intermediary MAY process If-Match based upon the contents of its cache, replying with 4xx when..." (note that that's just rapid hand-waving, not suggested spec text).
> 
> If we did that, we'd have a header whose handling by origin servers was mandatory for some methods, and handling by intermediary servers was optional for other methods. Not sure how much that would confuse people, but properly spec'd, it'd probably be OK.
> 
> We'd also have to have a discussion about whether 412 was the right status code.
> 
> Roy, any thoughts?
> 
> Tom, can you say any more about your use case?

My thoughts would probably depend on the use case.
Note that the HTTP spec is only defining rules for communication
between independent components.  Although the internal architecture of
a user agent might include something like an HTTP cache, HTTP's rules
do not limit communication between the UA and its own internal cache.
As far as HTTP is concerned, they are both part of the user agent.

Thus, the sentence in 3.1:

   It can also be used with safe
   methods to abort a request if the selected representation does not
   match one already stored (or partially stored) from a prior request.

is referring to one already stored on the user agent from a prior
request by that user agent.

Originally, If-Match was defined to be answerable by intermediaries
for GET/HEAD requests.  However, 412 was considered by the WG to be an
undesirable response in those cases, so If-Range was created to
replace that function. My guess is that's the use case here. OTOH,
a 412 might be preferred for safe methods other than GET and HEAD.

AFAICR, limiting If-Match requirements to origin servers in RFC7232
was due to lack of implementation by clients (aside from the unsafe
methods) and a desire for semantic consistency for the field.

For unsafe methods, the client's field value is referring to the
current selected representation on the origin server, which is something
that can only be tested by the origin server. Having a special-case for
safe methods meant that both the meaning of the field changed per
method and the need to implement it changed per method, which is quite
a bit of complexity for a feature that nobody ever used.

BTW, Apache httpd implements If-Match in the default resource handler
and anywhere that calls ap_meets_conditions().  That will result in a
412 response to an otherwise successful request if the etag given
doesn't match the selected representation, regardless of the method.
[I haven't tested it to see if that gets called by default when the
server is installed as an intermediary.]

Cheers,

....Roy

Received on Tuesday, 28 February 2017 01:05:08 UTC