Weak ETags and the If-Match header

1

Hi,

Sorry about the links here, as I am new the forum software won’t let me include more than 2 links.

Link 1: https://www.hl7.org/fhir/http.html
Link 2: https://tools.ietf.org/html/rfc7232

I would like a bit of clarification regarding FHIR and ETags.

This section Link1#versioning gives me the impression that ETags in FHIR are always weak, and should always be wrapped in W/“tag”. The documentation at Link1#concurrency reinforces this impression, and has an example where the If-Match header is set to a weak ETag value.

Is it correctly understood that FHIR servers/clients should always be using weak ETags, and never strong ETags, including in the If-Match header?

The HTTP documentation for ETags mentions that If-Match should always be used with strong ETags Link2#section-3.1, as weak ETags can’t match when using this header (see Link2#section-2.3.2).

Is the example at Link1#concurrency wrong to use an If-Match with a weak ETag, or is FHIR out of sync with the HTTP spec regarding how to interpret this header?

2

Good question. Further discussion at https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Weak.20ETags.

Some background:

  • can’t use strong ETags because of the accept/content-type headers (discussed that with IETF Wg lead)
  • I think we missed the rules on strong ETags when we documented the use of if-match
  • But under the rules of the HTTP spec, there’s no way to handle etags and if-match correctly in the presence of variable mime types
  • I think that the HTTP spec is wrong here; the server can properly evaluate the intent of the if-match header without using strong etags. But note that the language is actually “An origin server MUST use the strong comparison function when comparing entity-tags for If-Match” - that’s not actually the same as

If-Match should always be used with strong ETags

So there’s an interpretational question there

3

Thanks Grahame.

But note that the language is actually “An origin server MUST use the strong comparison function when comparing entity-tags for If-Match” - that’s not actually the same as "If-Match should always be used with strong ETags"

That’s true, but the table at https://tools.ietf.org/html/rfc7232#section-2.3.2 shows that weak ETags can’t match using the strong comparison function. This is why I infer that using a weak ETag in If-Match doesn’t make sense, as a weak ETag can never match when used in that header.

In any case, if following the exact rules for If-Match while also handling variable mime types isn’t possible, bending the HTTP spec a bit might be okay for now(?). Maybe the IETF can clarify/relax that rule?

Is it correctly understood that the FHIR spec doesn’t allow for strong ETags, and we should always be using weak ETags? I’m asking as I’ve seen the HAPI FHIR client send If-Match without the W/ prefix, and I’m wondering whether it makes sense to raise a bug for it.