-
Notifications
You must be signed in to change notification settings - Fork 185
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conform to RFC6902 replacement semantics #85
Conform to RFC6902 replacement semantics #85
Conversation
Sorry for the delay. Could you add some tests about how this changes the functionality of test and copy as well, which use get. |
Sure. I’ll get those done tomorrow.
…On Sun, Nov 3, 2019 at 1:11 PM Evan Phoenix ***@***.***> wrote:
Sorry for the delay.
Could you add some tests about how this changes the functionality of test
and copy as well, which use get.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#85?email_source=notifications&email_token=AAABPK4QUFI5GNKVPGE6BHDQR4A4XA5CNFSM4IKEMWKKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEC5ZDNA#issuecomment-549163444>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAABPK5ZFVI4ZBPVGRNQR6DQR4A4XANCNFSM4IKEMWKA>
.
|
A "replace" patch operation referencing a key that does not exist in the target object are currently being accepted; ultimately becoming "add" operations on the target object. This is incorrect per the specification: From https://tools.ietf.org/html/rfc6902#section-4.3 section about "replace": The target location MUST exist for the operation to be successful. This corrects the behavior by returning an error in this situation.
Alrighty. I've added some additional tests. For the most part, the tests you have are adequate to test for any change in behavior for these other verbs. The only one that is going to change seems to be |
Any thoughts about this? |
Scratch that last comment, we've figured out a way of bridging the fix without requiring a patch release :) |
@logicalhan I could do a 4.5.1 if that makes it easier. |
:) thanks, but I think we can actually use the git sha, it seems that the exponential fix went in prior to the RFC change thing, so we can directly peg against that. @liggitt to verify though. |
Ok, please just let me know. Happy to sort it out either way.
…On Mon, Jun 8, 2020 at 4:54 PM Han Kang ***@***.***> wrote:
@logicalhan <https://github.com/logicalhan> I could do a 4.5.1 if that
makes it easier.
:) thanks, but I think we can actually use the git sha, it seems that the
exponential fix went in prior to the RFC change thing, so we can directly
peg against that. @liggitt <https://github.com/liggitt> to verify though.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#85 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAAAB7EDZB6AI3RC72AH63RVV23HANCNFSM4IKEMWKA>
.
|
Yeah, I think we've decided to use the sha that includes the exponential fix but not the RFC one, so it won't be necessary. Really appreciate it though :) |
A "replace" patch operation referencing a key that does not exist in the target object are currently being accepted; ultimately becoming an "add" operation on the target object. This is incorrect per the specification:
From https://tools.ietf.org/html/rfc6902#section-4.3 section about
"replace":
This corrects the behavior by returning an error in this situation.
📎 #78