Closed darrelmiller closed 2 years ago
jayadeba
commented
2 years ago @darrelmiller Thanks for the pointer. This is good to know and definitely needs collaboration. We have also received a mail from the Author (Dr. Ralf Handl) of the OASIS draft to collaborate on this.
Interestingly, the draft mentions using these headers even for idemepotent methods like PUT & DELETE as well.
We'll work on this with the OASIS authors.
Issue is noted.
dret
commented
2 years ago On 2021-07-27 03:44, Darrel wrote:
OASIS has a specification for a header that performs the same function. https://docs.oasis-open.org/odata/repeatable-requests/v1.0/cs01/repeatable-requests-v1.0-cs01.html#_Toc45116383 https://docs.oasis-open.org/odata/repeatable-requests/v1.0/cs01/repeatable-requests-v1.0-cs01.html#_Toc45116383
that indeed was a very interesting spec to discover, i heard about it yesterday. for a quick overview of the header fields it defines, here's where it has been added to web concepts:
https://webconcepts.info/specs/OASIS/standard/repeatable-requests-v1.0
Interestingly, the OASIS spec has a couple of other features (Repeatability-First-Sent, Repeatability-Client-ID) that helps a server manage the set of idempotency keys that the server needs to keep track of. It would be interesting to understand how current implementations of the Idemptotency-key addresses handle this same concern.
it does indeed seem to be a bit more constrained than the current proposal for Idempotency-Key. Idempotency-Key has some text about expiration, but no mechanisms for managing it:
https://datatracker.ietf.org/doc/html/draft-ietf-httpapi-idempotency-key-header#section-2.3
another additional constraint is that the OASIS spec mandates supporting certain types of keys: "Servers MUST accommodate the 36-character hexadecimal case-insensitive encoding of a UUID (GUID)." i am not quite sure what than means (is comparing keys in case-sensitive ways a function of a certain key syntax?), but it seems like another difference of the two specs.
dret
commented
2 years ago On 2021-07-27 05:11, jayadeba wrote:
@darrelmiller https://github.com/darrelmiller Thanks for the pointer. This is good to know and definitely needs collaboration. We have also received a mail from the Author (Dr. Ralf Handl) of the OASIS draft to collaborate on this.
just pointing it out: the OASIS spec is stable, the headers have been registered by IANA, and the whole effort seems to be part of the general OData effort, even though it's explicitly mentioned as being usable outside of this framework as well:
sdatspun2
commented
2 years ago Discussed in 111. Sought opinions of the WG re how to proceed.
There are 4 headers in that spec: Repeatability-Request-ID, Repeatability-First-Sent, Repeatability-Client-ID and Repeatability-Result. And repeatability is applicable to 2 methods (PUT, DELETE) that are supposed to be idempotent by the HTTP spec.
"Servers MAY support repeatability on POST, PUT, PATCH and DELETE"
dret
commented
2 years ago On 2021-07-28 00:56, Sanjay Dalal wrote:
There are 4 headers in that spec: Repeatability-Request-ID, Repeatability-First-Sent, Repeatability-Client-ID and Repeatability-Result. And repeatability is applicable to 2 methods (PUT, DELETE) that are supposed to be idempotent by the HTTP spec. "Servers MAY support repeatability on POST, PUT, PATCH and DELETE"
this indeed is a curious statement. i sent an email to the OData comments list asking for clarification what this means:
https://lists.oasis-open.org/archives/odata-comment/202107/msg00000.html
darrelmiller
commented
2 years ago I believe this issue has served its purpose to have a conversation around the two different specifications. I think the OASIS specification defines an approach that while potentially offering more features, it puts some additional constraints on server implementations. I think it is reasonable to expect that both the Repeatable Request approach and Idempotency Key approach will find use cases where one of them is the optimum choice.
I'm going to close this issue. Feel free to re-open if further discussion is required.
OASIS has a specification for a header that performs the same function. https://docs.oasis-open.org/odata/repeatable-requests/v1.0/cs01/repeatable-requests-v1.0-cs01.html#_Toc45116383
Interestingly, the OASIS spec has a couple of other features (Repeatability-First-Sent, Repeatability-Client-ID) that helps a server manage the set of idempotency keys that the server needs to keep track of. It would be interesting to understand how current implementations of the Idemptotency-key addresses handle this same concern.