Weak Etags | Redfish Specification Forum

wiebalck
Minnow

Posts: 1

Weak Etags Nov 15, 2021 15:36:38 GMT

Quote

Post by wiebalck on Nov 15, 2021 15:36:38 GMT

Hi!

Do I understand [1] correctly in that a Redfish resource should never have a weak Etag?

I am referring in particular to

"The ETag mechanism supports both strong and weak validation. If a resource supports an ETag, it shall use the RFC7232-defined ETag strong validator."

which I read as "HTTP allows for weak and strong Etags, but resources in Redfish should only use strong Etags."

This question is triggered by some hardware I am trying to use with Redfish and it returns a weak Etag for a resource, i.e. 'W/"12345"', and only accepts the full Etag, including the qualifier (!), when calling PATCH. This collides with my interpretation of the sentence above and also with how I understand IF-* preconditions should work (always fail on weak Etags).

Thanks for any clarification!
Arne

[1] redfish.dmtf.org/schemas/DSP0266_1.11.0.html#etags

mraineri
Administrator

Posts: 1,056

Weak Etags Nov 15, 2021 19:45:07 GMT

Quote

Post by mraineri on Nov 15, 2021 19:45:07 GMT

We updated that clause in version 1.13.1 of the spec to remove the "strong" requirement. We realized that strong ETags have specific rules for how they're used that conflict with some of the semantics of Redfish. For example, if a strong ETag were to be used in a Manager resource, the value of "DateTime" will be changing every second, thus invalidating the current ETag every time the value changes, making it impossible to PATCH.

Ultimately from a client's perspective, the ETag you read in the response will need to be provided in the request header when attempting to PATCH the resource, regardless of it being strong or weak. We simply expect the client to treat it as an opaque value. So, if the service provides you with a weak ETag, that same weak ETag would be in your request header for the PATCH operation.

dtantsur
Minnow

Posts: 1

Weak Etags Nov 16, 2021 8:53:56 GMT

Quote

Post by dtantsur on Nov 16, 2021 8:53:56 GMT

Hi Mike,

> the ETag you read in the response will need to be provided in the request header when attempting to PATCH the resource, regardless of it being strong or weak

The RFC is very clear on the fact that strong matching is used for the If-Match header: httpwg.org/specs/rfc7232.html#header.if-match.

The Mozilla documentation developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-Match puts it even clearer:

> If a listed ETag has the W/ prefix indicating a weak entity tag, this comparison algorithm will never match it.

Your suggestion goes against RFC 7232. Furthermore, we have encountered hardware that required stripping the W/ part of the weak etag before sending it back (which is also not RFC compliant FWIW).

I think the best option for DMTF is to go the opposite direction: if an endpoint require an ETag in the PATCH or PUT request, the corresponding resource representation MUST include a *strong* ETag.

Cheers,
Dmitry

Last Edit: Nov 16, 2021 8:55:14 GMT by dtantsur: Added PUT

mraineri
Administrator

Posts: 1,056

Weak Etags Nov 16, 2021 14:50:16 GMT

Quote

Post by mraineri on Nov 16, 2021 14:50:16 GMT

Yes, we realize it's non-conformant. However, we think that for the sake of usability, we'd want to allow for weak ETags in request headers to avoid requiring clients to interpret the ETags themselves.

The specification is clear with regards to clients supplying the same ETag found in GET responses in a subsequent PATCH/PUT operation. If you're encountering services that require reformatting the ETag for the request, I suggest reaching out to the appropriate vendors to raise the issue.