feat(method): add QUERY method#798
Conversation
|
Though, I wouldn't be opposed to waiting ever so slightly with merging this, to allow the IETF to finish, and include it in v1.5 instead of v1.4. |
seanmonstar
force-pushed
the
push-lxlvmqrmmnsp
branch
from
8c7f820 to
cec37ba
Compare
|
It has just been fully accepted today: https://www.rfc-editor.org/info/rfc10008/ So let's merge 😎 |
| // This is purposefully excluded because of potential conflict with the | ||
| // URI query. | ||
| // pub fn query() -> Builder |
There was a problem hiding this comment.
Bit late here, but could this be added as perhaps http_query if there is concern about a conflict?
For what it's worth, I don't find the conflict too worrisome: if there were a method to get the URI query, I'd expect that to be called uri_query, and this being a zero-param associated function (rather than a method to get the URI query, or a 1-param function to build a GET with one) is a pretty big clue.
There was a problem hiding this comment.
I don't mean confusion, but that it would prevent any addition of req.query() since it's on the same type.
Is that lack of this easy builder a big deal? It's also possible to do Request::builder().method("QUERY").
There was a problem hiding this comment.
It certainly isn't a big deal aside from consistency, these constructors aren't used directly all that frequently (at least IME).
I think there is still a case for spending the query name on this purpose, though; the typing savings from ::builder().method("QUERY") -> ::query() are quite a bit more than .uri().query() -> .query().
2 participants
IESG has just confirmed promoting QUERY to Proposed Standard: https://lists.w3.org/Archives/Public/ietf-http-wg/2025OctDec/0208.html