digest: B.7. POST Response does not Reference the Request URI

[reschke]

The representation enclosed in the response refers to the resource identified by Content-Location (see Section 6.4.2 of [HTTP]). Repr-Digest is thus computed on the enclosed representation.

I'm not sure I understand the role of Content-Location here. Are you saying things were different if C-L was not present?

[reschke]

At the end of the day, what the spec needs to describe is what "Repr-Digest" applies to in general; in particular for a response to an unknown/new HTTP method. That algorithm can special-case existing methods, but it absolutely needs to answer it for the general case as well.

[ioggstream]

Are you saying things were different if C-L was not present?

The question is "which is the representation data" ?
C-L helps in identifying the resource, and thus the representation data.

In this case, R-Digest would have been the same for a 201 response:

• if C-L is set, the hash is the one of the referenced resource
• if C-L is not set, the hash is just the one related to the status of the request.

what the spec needs to describe is what "Repr-Digest" applies to in general

The text is in an example, so it is not normative.

in particular for a response to an unknown/new HTTP method.

That depends on the method semantic, that is expected to define which is the representation data. Since the representation data in HTTP depends on the method semantics and on the status code, IMHO the general behavior of R-Digest for an unknown method should be (in this case) 501 or 405.

[reschke]

In this case, R-Digest would have been the same for a 201 response:

• if C-L is set, the hash is the one of the referenced resource
• if C-L is not set, the hash is just the one related to the status of the request.

"is just the one related to the status of the request" - hm, no. It's whatever is in the response content, no? In this case, that happens to be content describing the status, but in general that's not necessarily true.

That depends on the method semantic, that is expected to define which is the representation data. Since the representation data in HTTP depends on the method semantics and on the status code, IMHO the general behavior of R-Digest for an unknown method should be (in this case) 501 or 405.

1. I don't understand what "the behaviour ... should be 501 or 405".
2. The HTTP spec specifies the case for unknown methods (it's the same as for POST)

I really think the examples need more work to make sure that they do not create confusion instead of clarifying things. Even if they are not normative.

[ioggstream]

If's whatever is in the response content

Question: look at the request/response below:

1. is the response using 204 + C-L valid?
2. does the presence of C-L state that the representation data of /foo/bar is the empty byte sequence?

--- request
POST /foo HTTP/1.1
C-T: application/json

{ "hello": "world" }
--- response
HTTP/1.1 204 No Content
C-L: /foo/bar
Location: /foo/bar

---

[reschke]

yes, and yes.I think.

See https://www.rfc-editor.org/rfc/rfc9110.html#section-6.4.2-5.6