http-extensions icon indicating copy to clipboard operation
http-extensions copied to clipboard

Another approach to QUERY

Open mnot opened this issue 2 years ago • 5 comments

Reading the remaining issues on QUERY, I'm starting to wonder if it would help to define it as a transformation on a GET request -- i.e., the body on QUERY becomes the query string on a GET URI, with the transformation governed by the media type on the QUERY.

That would clarify things like caching, identity, and conditional requests.

Just thinking out loud...

mnot avatar Oct 13 '23 05:10 mnot

I don't think that you want to REQUIRE that implementations treat it that way, but a suggestion that they could might help.

martinthomson avatar Oct 13 '23 06:10 martinthomson

Oh yes, this wouldn't necessarily be reflected on the wire or internally in implementations -- it's just how we talk about it / specify it.

mnot avatar Oct 13 '23 07:10 mnot

That's sort of how I've thought about it all along, so I haven't really considered the option of having another perspective. But now that you bring it up, I can see how being more explicit about this correlation in the spec might be helpful. Thumbs up!

asbjornu avatar Oct 15 '23 22:10 asbjornu

This sounds interesting.

However, it would conflict with the case where the target URI of the QUERY request already contains a query part (I don't believe it's a common use case, but it would still be a weird conflict).

reschke avatar Nov 05 '23 13:11 reschke

However, it would conflict with the case where the target URI of the QUERY request already contains a query part (I don't believe it's a common use case, but it would still be a weird conflict).

Good point. Perhaps we could declare that to be a request error where 400 Bad Request, 422 Unprocessable Entity, or similar, is a warranted response?

asbjornu avatar Nov 07 '23 09:11 asbjornu

IETF 120 meeting feedback: the clash of two potential query parts probably makes this tricky.

reschke avatar Jul 22 '24 20:07 reschke