Post by malbolge on Jun 5, 2023 14:52:24 GMT
This comes from RDE but ought to be 100% the same in Redfish.
ETag operations, such as match/no-match, allow a Redfish request to be optionally supplied with an ETag. For example, a user may request Redfish/RDE to PATCH a Resource, but only if the ETag of this Resource still has the same value from when it was last read, indicating it didn't change since then.
Redfish specification explicitly allows strong and weak ETags. The difference is that a strong ETag guarantees uniqueness (by using a change counter or similar), whereas a weak ETag is at risk of hash conflict.
So far, so good.
The rules on ETag comparisons are dictated by datatracker.ietf.org/doc/html/rfc7232
RFC7232 has a section detailing the mechanism of ETag comparison. There's two methods:
+--------+--------+-------------------+-----------------+
| ETag 1 | ETag 2 | Strong Comparison | Weak Comparison |
+--------+--------+-------------------+-----------------+
| W/"1" | W/"1" | no match | match |
| W/"1" | W/"2" | no match | no match |
| W/"1" | "1" | no match | match |
| "1" | "1" | match | match |
+--------+--------+-------------------+-----------------+
The Redfish specification doesn't say which comparison method to use.
Practically speaking, devices that use Weak ETags must also use the Weak Comparison algorithm, otherwise it will never match. Devices that use Strong ETags can use the Strong comparison.
Is the ETag comparison algorithm deliberately left undefined and up to the RDE/Redfish implementer?
ETag operations, such as match/no-match, allow a Redfish request to be optionally supplied with an ETag. For example, a user may request Redfish/RDE to PATCH a Resource, but only if the ETag of this Resource still has the same value from when it was last read, indicating it didn't change since then.
Redfish specification explicitly allows strong and weak ETags. The difference is that a strong ETag guarantees uniqueness (by using a change counter or similar), whereas a weak ETag is at risk of hash conflict.
So far, so good.
The rules on ETag comparisons are dictated by datatracker.ietf.org/doc/html/rfc7232
RFC7232 has a section detailing the mechanism of ETag comparison. There's two methods:
+--------+--------+-------------------+-----------------+
| ETag 1 | ETag 2 | Strong Comparison | Weak Comparison |
+--------+--------+-------------------+-----------------+
| W/"1" | W/"1" | no match | match |
| W/"1" | W/"2" | no match | no match |
| W/"1" | "1" | no match | match |
| "1" | "1" | match | match |
+--------+--------+-------------------+-----------------+
The Redfish specification doesn't say which comparison method to use.
Practically speaking, devices that use Weak ETags must also use the Weak Comparison algorithm, otherwise it will never match. Devices that use Strong ETags can use the Strong comparison.
Is the ETag comparison algorithm deliberately left undefined and up to the RDE/Redfish implementer?
