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)