Missing HTTP verb: QUERY

[Vectorial1024]

Laravel Version

13.8.0

PHP Version

8.5.7

Database Driver & Version

N/A

Description

The HTTP QUERY verb RFC is now in the Standards Track:

https://www.rfc-editor.org/info/rfc10008/

RFC 10008: The HTTP QUERY Method

[...]

This is an Internet Standards Track document.

To summarize the RFC, the QUERY verb behaves like a GET verb that has a valid and meaningful body just like the POST verb, and QUERY responses are cacheable which is different from the POST verb. It allows for APIs that query resources in highly expressive and intricate ways without sacrificing cacheability.

Currently, Laravel does not have any way to make use of this HTTP verb. This is a problem.

Given that this RFC is new, it may be desirable to add support to the QUERY verb as soon as possible to indicate that Laravel is aware of new developments in the general internet world and is following latest trends.

Steps To Reproduce

N/A

[rodrigopedra]

That link is a proposal, right?

Are there any frameworks, in any programming language, implementing it already?

Also, are there any server runtimes (Node.js, Python, etc.) that support it already?

[macropay-solutions]

@Vectorial1024

Currently, Laravel does not have any way to make use of this HTTP verb. This is a problem.

You can:

    public function get($uri, $action = null)
    {
        return $this->addRoute(['GET', 'HEAD'], $uri, $action);
    }

framework/src/Illuminate/Routing/Router.php

Line 158 in 4f65316

public function get($uri, $action = null)

You can Write Route::addRoute(['QUERY', 'HEAD'], '/example', ....

[macropay-solutions]

@rodrigopedra
|Are there any frameworks,
Symfony 7.4

[rodrigopedra]

Symfony added support to it just to its HTTP Client component, the one that wraps curl.

On their Http Foundation they added a constant to a class, but nothing more, no routing support, no body parsing, no checks for idempontency, at least not yet as of today.

If I understand well, Maravel is your fork from Laravel with patches that didn't make the cut on PRs here and other changes you deemed important, right?

It is great that you add experimental features to your fork, but adding a feature is a kind of maintenance compromise on the long run, adding support to proposals not yet made official is a tricky decision on this regard.

Out of curiosity, isn't your fork's name ("Maravel") close enough to Laravel to infringe its trademark?

I am not a lawyer, and I believe as long it is a personal fork there souldn't be a problem.

But when you start promoting it as an alternative framework, as you do here listing it as an example of this feature being adopted, I guess it could be a trademark infringement.

[shaedrich]

There are different HTTP verbs, depending on what you are doing (e.g. WebDAV has COPY, LOCK, MKCOL, MOVE, PROPFIND, PROPPATCH, and UNLOCK). Laravel doesn't implement all of them, because there is not necessarily a huge benefit on the framework level, but there could be on a package level.

Since Route::get(), Route::post(), Route::put(), Route::patch(), Route::delete(), and Route::options() are just shortcuts, you can still use any HTTP verb you like with Laravel:

framework/src/Illuminate/Routing/Router.php

Line 158 in 4f65316

public function get($uri, $action = null)

You can Write Route::addRoute(['QUERY', 'HEAD'], '/example', ....

[rodrigopedra]

@marius-ciclistu no worries, I thought on bringing this matter to attention not to push you back from working on Maravel, but to maybe considering any risks on your continued effort.

I am neither a maintainer nor a trademark expert or attorney. So please take my words lightly and not as a criticism.

[Vectorial1024]

It's disappointing that this got moved to the discussion channel while I was unavailable, but given that indeed Laravel has e.g. Route::get(), Route::post() and etc., it makes sense to also add support for a hypothetical Route::query(). This QUERY verb is not part of the WebDAV. Given that I am proposing an extra case on something that already exists in Laravel, it really should stay on the Issues channel.

Given the vast volume of discussion topics being created and commented on, I can imagine this topic is gonna be forgotten and no support for the QUERY verb will be added. Would be lucky if we can use Route::query() in Laravel 14.

I consider the proposed Route::addRoute() a temporary quick-fix until Laravel properly adds in the requested Route::query() helper method.

[shanerbaner82]

For anyone following this: QUERY support is now actively moving in PRs.

• Add query route method support #60655 (open, targeting master) adds first-class routing support, Route::query(), inclusion in Route::any(), and CSRF treating QUERY as a read request. An earlier version (Add QUERY route method support #60650) was closed only because the contract change meant it had to target master rather than 13.x.
• I've opened [13.x] Add query and queryJson HTTP testing helpers #60662 (targeting 13.x) adding $this->query() / $this->queryJson() testing helpers to MakesHttpRequests, so QUERY routes can be tested fluently. This works today even without Add query route method support #60655, since Route::match(['QUERY'], ...) already registers QUERY routes.
• I've also opened [13.x] Add Http::query() method to the HTTP client #60663 (targeting 13.x) adding Http::query() to the HTTP client for the consuming side, the same component Symfony chose to support first.

Worth noting since it came up above: as of Symfony 7.4 (Laravel 13's minimum), HttpFoundation supports QUERY beyond just a constant, Request::create() places parameters in the request body like POST/PUT/DELETE, and Request::createFromGlobals() parses QUERY request bodies. And QUERY is no longer a draft, it was published as RFC 10008 on the Standards Track.

[martinszeltins]

I cannot imagine trying to explain this to my grandchildren. Look, we had a GET method, but we kept ignoring the body/payload so we created a new method QUERY which does the same thing as GET but this time we do not ignore the body. Oh boy..

[Vectorial1024]

To be honest, the specs were for some reason very vague. "Body is optional", so what does that mean for everyone to choose one of the following:

• reject anything that has a body
• pass the body along (this could be extra large, back in the 80s could mean trouble)
• drop the body

What would be the correct answer? No one knows. Current practice is "drop the body", which means the spec guys had to invent the QUERY verb.

[martinszeltins]

The body is also optional for POST request, you do not NEED to send the body. Also worth noting is that some websites DO use the body with GET like Elasticsearch. There is no reason to reject or drop the body. If you don't want the body, just simply don't send it.

And now if we wanted to start using the body then why not just start using it? That would require us to update our clients/servers. Sure. But inventing a new method also requires to update clients & servers. Either way. And in most cases the server is not the issue, it is the at the application / framework level more than anything which makes it even easier.

Anyway, it is one of those patch on top of a patch because we messed up.. oops...

[joelbutcher]

For any who are interested in seeing QUERY added to 13.x, I've opened a PR that backports #60655 to 13.x, adding CSRF protection and removing the breaking change to the Registrar contract.

[Icaro0310]

Until there's first-class support, you can register it yourself — Router::match() accepts arbitrary verbs:

Route::match(['QUERY'], '/search', SearchController::class);

It isn't matched by Route::any()/Route::fallback(), because Router::$verbs is hardcoded to GET, HEAD, POST, PUT, PATCH, DELETE, OPTIONS. Routing itself works since Route::matches() just does in_array($request->getMethod(), $this->methods()), and Symfony's Request::getMethod() passes through unknown-but-valid method tokens like QUERY (it's only method spoofing via _method/X-HTTP-METHOD-OVERRIDE that's restricted to a known list).

Two caveats I hit: Symfony doesn't populate the $request->request bag for non-POST bodies, so read the query payload via $request->getContent()/$request->json() rather than input(). And a framework-level Route::query() would need QUERY added to Router::$verbs plus a helper — probably a decent PR candidate now that the RFC is on Standards Track.

—
Related work of mine: github.com/Icaro0310 · Website: icaro0310.github.io

[Vectorial1024]

I myself was initially confused by this situation; there is ambiguity when it comes to the wording. The thread was converted from an Issue so the timeline is unusual for a Discussion. There is also interest to review the situation after all these time.

HTTP QUERY was previously published as RFC 10008.

There are three types of "HTTP QUERY support":

• To send outgoing HTTP requests via Http facade
• To receive incoming HTTP requests at the route list
• To mock HTTP requests in test suites

To summarize the situation by time line:

• Laravel 13.19 https://github.com/laravel/framework/releases/tag/v13.19.0
  • allows sending outgoing HTTP QUERY requests [13.x] Add Http::query() method to the HTTP client #60663
  • allows mocking HTTP QUERY requests [13.x] Add query and queryJson HTTP testing helpers #60662
• Laravel 13.xx (upcoming)
  • allows receiving incoming HTTP QUERY requests (backport; contract unchanged) [13.x] Add QUERY route method support #61797
• Laravel 14 (expected)
  • allows receiving incoming HTTP QUERY requests (modifies contract) Add query route method support #60655

Great help by @shanerbaner82 for clarifying the situation and presenting the initial PRs #60564 (comment) . Also good catch to backport HTTP QUERY receipients #60564 (comment) .

For older Laravel versions (do upgrade asap regardless), we may still use Route::match():

since Route::match(['QUERY'], ...) already registers QUERY routes.

---

The situation for HTTP QUERY support in Laravel should then be well-addressed.