7 ms·

Wait until you realize that the difference between path and query string is entirely arbitrary and decided by the server. Query strings should never have existe

by nrds 4mo ago

Wait until you realize that the difference between path and query string is entirely arbitrary and decided by the server. Query strings should never have existed. They are an implementation detail of CGI webservers that leaked all over everything and now smells really bad.

paulddraper 4mo ago
How do you figure? Paths are hierarchical; query strings are name/value. (Note I speak of common usage.) You can create a different convention, but that one is pretty dang useful.
jolmg 4mo ago
It's arbitrary to a degree like the difference between using an attribute or child element in XML, but it's not entirely arbitrary. If you want to include data in the URL that's not part of the hierarchy of the path, query strings are good for that.
gpvos 4mo ago
Query strings existed before CGI did, and the way they're defined to be filled in from web forms is quite useful; I wouldn't want to need Javascript to fit that into path format. There's nothing wrong about having things decided by the server; I don't get that part of your argument at all.
- cobbzilla 4mo ago
  Maybe dumb question: how does the server “decide” anything other than what file to serve? Today we have many choices but back in the day CGI was the first standard way to do it. So yes query parameters existed before CGI but to use them you had to hack your server to do something with them (iirc NCSA web servers had some magic hacks for queries). CGI drove standardization.
  - stirfish 4mo ago
    func specialHandler(w http.ResponseWriter, r *http.Request) { if time.Now().Weekday() == time.Tuesday { http.NotFound(w, r) return } fmt.Fprintln(w, "server made a decision") } Your server can make decisions however you program it to, you know? It's just software. Forgive the phone-posting.
    - deleted 4mo ago
      [deleted]
    - cobbzilla 4mo ago
      and what server software is running this code in 1995?
      - lispwitch 4mo ago
        CL-HTTP or AOLserver
        cobbzilla 4mo ago
        sure looks like VB there, what’s the plugin? Didn’t see anything like that before.
        heavensteeth 4mo ago
        That's Go.
        cobbzilla 4mo ago
        Which runs on what computer in 1995?
        stirfish 4mo ago
        I'm not sure what point you're trying to make. Here it is in C, so you can run it on you computer in 1995? Because servers could make decisions in 1995. int main() { int s = socket(AF_INET, SOCK_STREAM, 0); setsockopt(s, SOL_SOCKET, SO_REUSEADDR, &(int){1}, sizeof(int)); struct sockaddr_in addr = { AF_INET, htons(8080), .sin_addr.s_addr = INADDR_ANY }; bind(s, (struct sockaddr*)&addr, sizeof(addr)); listen(s, 10); printf("Listening on :8080\n"); while (1) { int c = accept(s, NULL, NULL); char req[1024] = {0}; read(c, req, sizeof(req) - 1); time_t now = time(NULL); int tuesday = localtime(&now)->tm_wday == 2; const char *status = tuesday ? "404 Not Found" : "200 OK"; const char *body = tuesday ? "Not Found (it's Tuesday)" : "Hello from 1995!"; char resp[256]; snprintf(resp, sizeof(resp), "HTTP/1.1 %s\r\n" "Content-Length: %zu\r\n" "Connection: close\r\n\r\n%s", status, strlen(body), body); write(c, resp, strlen(resp)); close(c); } }
  - losvedir 4mo ago
    TCP has been around a long time. Listen, read, send, you're good to go. It's just software so you can make it do anything. But you're asking about the relationship between popular primarily file serving servers like Apache and their relationship to high level code to create custom responses? Yeah, CGI was the first big standard there that I remember, though it was a bit before my time. But that's only one possible architecture. These days, most web apps have the web server built in, and so the custom code you're writing works with the full request directly. There may be a lightweight web server in front (or multiple), like nginx, to manage connections, but they will largely just proxy the whole thing through.
    - cobbzilla 4mo ago
      I was responding to: > Query strings existed before CGI did… There's nothing wrong about having things decided by the server Sure, but there is also no standard for how to format/parse the query string. And also no server plugin frameworks. So you are inventing your own standard and extending some HTTP server for which you have source. Until CGI forces a standard, bad as it might be; it’s a common ground.
mikeocool 4mo ago
I dunno, it seems like the fact that we arrived at a fairly standard structure for URL paths that works pretty well is not a bad outcome. Seems a lot better than the other potential world we could lived in, where paths were a black box and every web server/framework invented their own structure for them.
- hamburglar 4mo ago
  My next website is going to have the path portion of the URL be a base64 encoded ASN.1 blob.
  - chrismorgan 4mo ago
    So long as it starts with a slash, go ahead! See how long it takes for someone to figure it out. It’s your website. Have fun with it! Do dumb things! :-)
  - rkeene2 4mo ago
    Make sure you use URL-safe base64 or the portions that looks like a path can get mangled MII//epi Is converted to MII/epi
    - yencabulator 4mo ago
      That would be broken software. https://en.wikipedia.org/wiki/// https://en.wikipedia.org/wiki///
- gritzko 4mo ago
  In my current project I use URIs to refer to absolutely any entity in a git(-ish) repo. Files, branches, revisions, diffs, anything. URI turns out to be a really good addressing scheme for everything. Surprise. But the most used and abused element is always the path. Query takes a lot of that mess away. Might have been unmanageable otherwise. https://github.com/gritzko/beagle https://github.com/gritzko/beagle
  - 4mo ago
halayli 4mo ago
Nothing you said here is correct. Paths, query strings, and fragments are all well defined entities. https://datatracker.ietf.org/doc/html/rfc3986#section-3.3 https://datatracker.ietf.org/doc/html/rfc3986#section-3.3
- sroussey 4mo ago
  It’s a string between ? and # isn’t well defined. Or it is and it says very little.
pverheggen 4mo ago
Not entirely arbitrary - forms that use the GET method instead of POST will append form values as query params. For sites without Javascript, it's great for things like search boxes, tables with sorting/filtering, etc. instead of POST, since it preserves your query in the URL. https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/form#method https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
- msandford 4mo ago
  It has always amazed me how much trouble the SPA folks are willing to go to in order to slowly rebuild just normal boring URLs with querystrings because users demand deep linking and back buttons and the like. Or you could accept that you're probably going to need a round trip to the server and use a normal URL and it's fine. For all but the absolute biggest websites in the world, anyhow. At Facebook or Google scale yeah it's needed.

by nrds 4mo ago

paulddraper 4mo ago

How do you figure? Paths are hierarchical; query strings are name/value. (Note I speak of common usage.) You can create a different convention, but that one is pretty dang useful.

jolmg 4mo ago

It's arbitrary to a degree like the difference between using an attribute or child element in XML, but it's not entirely arbitrary. If you want to include data in the URL that's not part of the hierarchy of the path, query strings are good for that.

gpvos 4mo ago

Query strings existed before CGI did, and the way they're defined to be filled in from web forms is quite useful; I wouldn't want to need Javascript to fit that into path format. There's nothing wrong about having things decided by the server; I don't get that part of your argument at all.

cobbzilla 4mo ago
Maybe dumb question: how does the server “decide” anything other than what file to serve? Today we have many choices but back in the day CGI was the first standard way to do it. So yes query parameters existed before CGI but to use them you had to hack your server to do something with them (iirc NCSA web servers had some magic hacks for queries). CGI drove standardization.
- stirfish 4mo ago
  func specialHandler(w http.ResponseWriter, r *http.Request) { if time.Now().Weekday() == time.Tuesday { http.NotFound(w, r) return } fmt.Fprintln(w, "server made a decision") } Your server can make decisions however you program it to, you know? It's just software. Forgive the phone-posting.
  - deleted 4mo ago
    [deleted]
  - cobbzilla 4mo ago
    and what server software is running this code in 1995?
    - lispwitch 4mo ago
      CL-HTTP or AOLserver
      - cobbzilla 4mo ago
        sure looks like VB there, what’s the plugin? Didn’t see anything like that before.
        heavensteeth 4mo ago
        That's Go.
        cobbzilla 4mo ago
        Which runs on what computer in 1995?
        stirfish 4mo ago
        I'm not sure what point you're trying to make. Here it is in C, so you can run it on you computer in 1995? Because servers could make decisions in 1995. int main() { int s = socket(AF_INET, SOCK_STREAM, 0); setsockopt(s, SOL_SOCKET, SO_REUSEADDR, &(int){1}, sizeof(int)); struct sockaddr_in addr = { AF_INET, htons(8080), .sin_addr.s_addr = INADDR_ANY }; bind(s, (struct sockaddr*)&addr, sizeof(addr)); listen(s, 10); printf("Listening on :8080\n"); while (1) { int c = accept(s, NULL, NULL); char req[1024] = {0}; read(c, req, sizeof(req) - 1); time_t now = time(NULL); int tuesday = localtime(&now)->tm_wday == 2; const char *status = tuesday ? "404 Not Found" : "200 OK"; const char *body = tuesday ? "Not Found (it's Tuesday)" : "Hello from 1995!"; char resp[256]; snprintf(resp, sizeof(resp), "HTTP/1.1 %s\r\n" "Content-Length: %zu\r\n" "Connection: close\r\n\r\n%s", status, strlen(body), body); write(c, resp, strlen(resp)); close(c); } }
- losvedir 4mo ago
  TCP has been around a long time. Listen, read, send, you're good to go. It's just software so you can make it do anything. But you're asking about the relationship between popular primarily file serving servers like Apache and their relationship to high level code to create custom responses? Yeah, CGI was the first big standard there that I remember, though it was a bit before my time. But that's only one possible architecture. These days, most web apps have the web server built in, and so the custom code you're writing works with the full request directly. There may be a lightweight web server in front (or multiple), like nginx, to manage connections, but they will largely just proxy the whole thing through.
  - cobbzilla 4mo ago
    I was responding to: > Query strings existed before CGI did… There's nothing wrong about having things decided by the server Sure, but there is also no standard for how to format/parse the query string. And also no server plugin frameworks. So you are inventing your own standard and extending some HTTP server for which you have source. Until CGI forces a standard, bad as it might be; it’s a common ground.

mikeocool 4mo ago

I dunno, it seems like the fact that we arrived at a fairly standard structure for URL paths that works pretty well is not a bad outcome. Seems a lot better than the other potential world we could lived in, where paths were a black box and every web server/framework invented their own structure for them.

hamburglar 4mo ago
My next website is going to have the path portion of the URL be a base64 encoded ASN.1 blob.
- chrismorgan 4mo ago
  So long as it starts with a slash, go ahead! See how long it takes for someone to figure it out. It’s your website. Have fun with it! Do dumb things! :-)
- rkeene2 4mo ago
  Make sure you use URL-safe base64 or the portions that looks like a path can get mangled MII//epi Is converted to MII/epi
  - yencabulator 4mo ago
    That would be broken software. https://en.wikipedia.org/wiki/// https://en.wikipedia.org/wiki///
gritzko 4mo ago
In my current project I use URIs to refer to absolutely any entity in a git(-ish) repo. Files, branches, revisions, diffs, anything. URI turns out to be a really good addressing scheme for everything. Surprise. But the most used and abused element is always the path. Query takes a lot of that mess away. Might have been unmanageable otherwise. https://github.com/gritzko/beagle https://github.com/gritzko/beagle
- 4mo ago

halayli 4mo ago

Nothing you said here is correct. Paths, query strings, and fragments are all well defined entities. https://datatracker.ietf.org/doc/html/rfc3986#section-3.3 https://datatracker.ietf.org/doc/html/rfc3986#section-3.3

sroussey 4mo ago
It’s a string between ? and # isn’t well defined. Or it is and it says very little.

pverheggen 4mo ago

Not entirely arbitrary - forms that use the GET method instead of POST will append form values as query params. For sites without Javascript, it's great for things like search boxes, tables with sorting/filtering, etc. instead of POST, since it preserves your query in the URL. https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/form#method https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...

msandford 4mo ago
It has always amazed me how much trouble the SPA folks are willing to go to in order to slowly rebuild just normal boring URLs with querystrings because users demand deep linking and back buttons and the like. Or you could accept that you're probably going to need a round trip to the server and use a normal URL and it's fine. For all but the absolute biggest websites in the world, anyhow. At Facebook or Google scale yeah it's needed.