-
Notifications
You must be signed in to change notification settings - Fork 43
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
RFC 5789: Content-Location header usage #20
Comments
We could change references to "payload" in the definition of However, 6.3.2. Identification (it'd be a lot clearer if that were "payload identification") identifies a payload by the Content-Location header, so that's a bit weird. We'd have to say something like:
That works, I guess, but I fear it's going to confuse even more people, without good examples and explanation. The other solution would be to just declare this a bug in the PATCH spec. We should consider folding PATCH into core at any rate... |
Isn't it pretty clear that the example is in conflict with https://greenbytes.de/tech/webdav/rfc7231.html#rfc.section.3.1.4.2.p.3:
So it seems to me that the semantics in PATCH are wishful thinking (returning the etag but not the content), and we need an erratum. |
On the one hand, the example is a bit silly because CL only has meaning when there is a payload. OTOH, the definition we have doesn't make any sense for 203-206 and who knows what comes after. Maybe we should just change it to
|
Maybe the PATCH deleted the representation body. Seriously though, we should probably file an erratum on PATCH. Unless we want to incorporate it. I don't have strong feelings about whether or not we limit C-L to status codes that opt into it, as long as new status codes have the option of using it too. |
I think the case, when PATCH removes resource isn't possible, it looks to
be designed for partial update. I can't imagine case when partial update of
something causes deletion of it.
In my opinion Roy's approach with limitation for CL header to status codes
is a solution. Your concern is: 'limiting CL to 200 and 201 only will block
from usage with all new 2xx codes', correct? If so, it could be formulated
as "When header used with 2xx status except 203-206...". It will allow to
apply CL to all new 2xx codes without modifying document for each and
remove the contraversial case with CL for status codes with no payload.
Does it make sense?
чт, 11 окт. 2018 г., 10:41 Mark Nottingham <notifications@github.com>:
… Maybe the PATCH deleted the representation body.
Seriously though, we should probably file an erratum on PATCH. Unless we
want to incorporate it.
I don't have strong feelings about whether or not we limit C-L to status
codes that opt into it, as long as new status codes have the option of
using it too.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#20 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AS4oQUOwQAxQP6BKxNp_pv3p0-ccRUwIks5ujvY0gaJpZM4KCmy7>
.
|
Perhaps, but that still doesn't avoid the issue with PATCH; giving the header special semantics depending on the status code and method in use isn't good practice. Errata against PATCH reported here. |
Now if the erratum was accepted, we could close this issue... |
The erratum is now accepted, so I believe we can close this ticket. |
The RFC 5789 describes the appropriate usage of Content-Location header in PATCH:
So, it means, that Content-Location header must appear only if the actual representation is the part of response body for PATCH.
Also the usage of Content-Location is mentioned in another RFC 7231:
So, accordingly to this information in both RFCs, the apropriate usage of Content-Location with state-changing requests are following:
Content-Location must appear in response only if response-body contains the new resourse representation.
But, there is also an example in RFC 5789:
How you can see, there is a Content-Location presented in response with 204 status code (No content). Of course, this response doesn't contain any body as well as new resource representation. This fact adds some ambiguity in Content-Location header description. What is the correct usage of this header?
The text was updated successfully, but these errors were encountered: