IETF Proposes HTTP Query Method in Draft RFC
The IETF has introduced a draft RFC for the new HTTP QUERY method
The Internet Engineering Task Force (IETF) is a standards body responsible for the Internet Protocol (TCP/IP) standards. The IETF operates as a non-profit organization.
The IETF develops and maintains the HTTP protocol, which is the foundation for most Internet communication. In a recent Internet-Draft, the IETF proposed a new HTTP QUERY method (slated to be published as RFC 10008).
Document Abstract:
This specification defines the QUERY method for HTTP. A QUERY requests that the request target process the enclosed content in a safe and idempotent manner and then respond with the result of that processing. This is similar to POST requests, but QUERY requests can be automatically repeated or restarted without concern for partial state changes.
What is the HTTP QUERY method trying to solve?
The HTTP GET method runs into limitations when the data being transferred is too voluminous to be encoded and passed in the request URI. This has become a frequent issue hence this proposal aims to solve this problematic pattern.
The Default
HTTP GET
As you can see from the curl command below, query parameters can become very lengthy. Add to this that any non-standard character forces URL encoding, which makes it inefficient for certain kinds of data due to the encoding overhead.
curl -v "https://www.coderevere.com/?blog=http&pagelimit=450&country=india&browser%20-=chromium&version=aba"
* Host www.coderevere.com:443 was resolved.
* IPv6: (none)
* IPv4: 106.51.42.33, 106.51.42.8
* Trying 106.51.42.33:443...
* Connected to www.coderevere.com (106.51.42.33) port 443
* ALPN: curl offers h2,http/1.1
* (304) (OUT), TLS handshake, Client hello (1):
* CAfile: /etc/ssl/cert.pem
* CApath: none
* (304) (IN), TLS handshake, Server hello (2):
* (304) (IN), TLS handshake, Unknown (8):
* (304) (IN), TLS handshake, Certificate (11):
* (304) (IN), TLS handshake, CERT verify (15):
* (304) (IN), TLS handshake, Finished (20):
* (304) (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / AEAD-AES256-GCM-SHA384 / [blank] / UNDEF
* ALPN: server accepted h2
* Server certificate:
* subject: CN=coderevere.com
* start date: Jun 25 05:48:47 2026 GMT
* expire date: Sep 23 05:48:46 2026 GMT
* subjectAltName: host "www.coderevere.com" matched cert's "www.coderevere.com"
* issuer: C=US; O=Let's Encrypt; CN=YR1
* SSL certificate verify ok.
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://www.coderevere.com/?blog=http&pagelimit=450&country=india&browser%20-=chromium&version=aba
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: www.coderevere.com]
* [HTTP/2] [1] [:path: /?blog=http&pagelimit=450&country=india&browser%20-=chromium&version=aba]
* [HTTP/2] [1] [user-agent: curl/7.71.1-DEV]
* [HTTP/2] [1] [accept: */*]
> GET /?blog=http&pagelimit=450&country=india&browser%20-=chromium&version=aba HTTP/2
> Host: www.coderevere.com
> User-Agent: curl/7.71.1-DEV
> Accept: */*
>
* Request completely sent off
The Alternative
HTTP POST
As an alternative, many web operators have switched to the HTTP POST method to send queries to the server. With this method, the queries are sent in the body and not in the URI, as they are with the GET method.
This is demonstrated below, albeit with a non-working example. With such requests, it is not clearly apparent if the queries being sent are safe or idempotent without explicit knowledge of the server and how it handles such resources.
curl -X POST -H "Content-Type: application/x-www-form-urlencoded" -d 'blog=http&pagelimit=450&country=india&browser -=chromium&version=aba' https://www.coderevere.com
<HTML><HEAD>
<TITLE>Access Denied</TITLE>
</HEAD><BODY>
<H1>Access Denied</H1>
You don't have permission to access "http://www.coderevere.com/" on this server.<P>
Reference #18.42a336a.1782539682.26b8e301
<P>https://errors.edgesuite.net/18.42a336a.1782539682.26b8e301</P>
</BODY>
</HTML>
The Solution
HTTP QUERY
The IETF Internet-Draft proposes the introduction of the QUERY method to solve this problem. The QUERY method will sit between GET and POST for requirements similar to the ones highlighted above.
As with POST, the query is passed as request content rather than using the URI approach of GET. The one big difference is that this method is inherently explicit and safe, making it easy for proxies to cache responses and perform automatic retries.
This is a great proposal, as it encourages web operators to move away from using GET with a body (which is non-standard) or using POST for non-writing requests.
An example of what the QUERY method would look like in action:
QUERY / HTTP/1.1
Host: www.coderevere.com
Content-Type: application/x-www-form-urlencoded
blog=http&pagelimit=450&country=india&browser -=chromium&version=aba
Below is a snapshot of a great table from the Internet-Draft that explains this:
