#TIL the query component of a URI is actually completely opaque.
-
#TIL the query component of a URI is actually completely opaque. There is no such thing as a "query parameter" defined in any spec that I can find -- the use of ampersands to delimit such "parameters" is purely conventional!
At some point (HTML4), the recommendation was to use *semicolons* instead: https://www.w3.org/TR/html4/appendix/notes.html#h-B.2.2
There is even a line of argument that says that query parameters are a misfeature and antipattern. Any "parameter" should be passed along with the request itself, not the URI
-
I guess you can think of "query parameters" as a form of "URL hacking" (putting various file extensions in the URL). Not something that should ultimately be exposed to users at all, but we're probably stuck with it on some level because of historical decisions.
-
Jean-Baptiste "JBQ" Quérureplied to infinite love ⴳ last edited by
@trwnh Yeah, for most people, URIs aren't used outside of HTML, so it's easy to assume that URIs only ever behave like they do in HTML, especially HTML forms. Same about Javascript, it used to be oddly difficult (back around 2005) to find books about Javascript that didn't assume an HTML execution environment (with DOM and all that).
-
@trwnh
Your Child on the Nice List? Send Them a Letter from Santa! - Shop Now
https://shorturl.at/8Hvy8 -
Ah wait, I found it -- it seems to have come about because of HTML 2.0 form encoding (application/x-www-form-urlencoded)
https://www.w3.org/MarkUp/html-spec/html-spec_toc.html#SEC8.2.2
and also likely popularized by QUERY_STRING for cgi-bin stuff
-
basically you encode all the form data using = and &
then if method=get you pass that along as the query component
or if method=post then you pass it along as the body of the HTTP request
and i guess it stuck that way despite GET for forms being a Bad Idea.
-
so in short, it looks like query parameters are just an evolution of form data parameters.
-
infinite love ⴳreplied to Jean-Baptiste "JBQ" Quéru last edited by
@jbqueru the form thing is really getting to me; i only found any of this out because i was looking at the problem of ordering "query parameters" causing two URIs to be semantically equivalent despite being syntactically different.
-
@trwnh doesn't that kind of depend on the type of form? Classically for a something like a search GET would be a more appropriate method than POST or PUT …
-
@oblomov maybe? i can see arguments for search being a POST.
-
@oblomov the semantic argument might be that GET is appropriate for when you want to refer to a query itself, for example using /search?bananas to search for "bananas". but the problems with GET are numerous:
- query components are often logged, while request bodies are not
- query components are limited in how complex they can get -- it's not easy to represent arrays, maps, hierarchical data, and so on
- search may be an expensive request, so better to not allow any old browser to do it -
@trwnh
Credit Card Debt over $20k? We Can Help - No Return pay
https://shorturl.at/6s7Ze -
@trwnh
#1 Weird Trick To End Tinnitus This Thanksgiving In Just 30 Seconds A Day
https://shorturl.at/E3GNR -
@trwnh
“Night Vision” Glasses Help Seniors Drive Safely At Night - Buy Now
https://shorturl.at/w7hNH -
@trwnh Unless I'm mistaken it's part of the CGI spec not URI spec.
-
@dalias yeah i figured this out downthread -- it's HTML 2.0 forms and application/x-www-url-formencoded when the form method=get
CGI also popularized it as well, although CGI takes the opaque QUERY_STRING so the convention mostly arises from html form encoding
-
@trwnh hm I'm not convinced. The main issue is that neither POST nor PUT are conceptually appropriate. Among the methods defined by HTTP, GET is the one that's conceptually closest. OTOH, those *are* problems with using a query string. Maybe they could be reduced by other means, such as additional headers or body payload (GET *can* have a payload)
-
@trwnh
ENENCE Instant Translator: Any Language, Any Country
https://shorturl.at/QSb7Z -
@oblomov well POST is "do something" not necessarily "create something". https://www.rfc-editor.org/rfc/rfc9110.html#section-9.3.3
> process the representation enclosed in the request according to the resource's own specific semantics
imo "take this request, parse some params out of it, then perform the action" is a valid way of thinking about search.
as for GET,
> requests transfer of a current selected representation for the target resource
is often but not always appropriate. depends on if you see results as a resource.
-
and that's what it really comes down to imo -- the use of a query component fundamentally alters the identity, you are asking for a different resource when you append the query component. /search and /search?query are different resources.
