Content-Location with QUERY

[MikeBishop]

Fixes #1745.

[mnot]

Content-Location doesn't indicate whether the resource on the other end will return these results in perpetuity, or whether it'll return the results to the query (which may change over time).

So it might be better to be explicit -- if the server wants to create a resource for these results, use 201 Created with Location that explicitly points to a resource that represents this query, and which can change over time. The server can choose whether to include the query results on the 201, of course.

[MikeBishop]

Given that we're defining this method, it seems like we can specify which is the intended behavior, or provide mechanisms for each.

[asbjornu]

Could perhaps a Link header be used to disambiguate the two use-cases?

Link: </updated-results>; rel="latest-version", </these-results>; rel="memento"

The chosen link relations are probably not appropriate, I just picked some that exists to provide a complete example.

[MikeBishop]

Per discussion in Brisbane side-meeting:

• Need to add text indicating what it means if the C-L target errors
• Add text clarifying that the resource can be cached despite the different URI (this is cautioned against in SEMANTICS)
• Security Considerations? Suggest that the URI SHOULD NOT expose the plaintext of the query contents (for Header to request always using QUERY over GET #1909)

[reschke]

Suggested change

[MikeBishop]

Review feedback from @reschke.

[martinthomson]

I see nothing here about cacheability or origins. I know that I left early, but I thought that we had concluded that the server claims about the Content-Location resource would be treated differently based on whether the indicated resource was on the same origin (or not).

[martinthomson]

Suggested change

	operation. A client can send a GET request for the indicated URI to repeat
	operation. A client can send a GET request for the indicated URI to repeat

So is this "A client can" or "This represents a claim from the server that a client can"

[MikeBishop]

@martinthomson, I've added language restricting it to same-origin; is there a stronger statement you were expecting to see here?

[reschke]

@mnot , @royfielding , @martinthomson - should we go ahead with this?

[royfielding]

No.

See #1745 (comment)

[reschke]

IETF 120 feedback: define both (the resource that identfies the result of this query), and a resource that can be used with GET to repeat the QUERY itself.

[reschke]

This looks good (right, @royfielding ?)

Looking at the PR, I was going to ask whether Location and Content-Location can be trailers, but found that this is consistent with RFC 9110.

Will have a look at the full text later to see how in integrates, and whether we may want to have more examples.

[reschke]

OK, I think we should add an example to section 4.

@MikeBishop - can you move this PR to the WG repo, so I can add to it?

[MikeBishop]

@reschke, GitHub doesn't let me change the source branch of a PR, only the target. I've pushed the same branch to the upstream repo and opened #2851 with the same commit history. You should have full access to that one.