Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I’ve banned query strings

chrismorgan.info

Post reply on HN
Print view View original

271–280 of 317 posts

Re: I’ve banned query strings

#271

Post by [deleted] »

mnahkies wrote: post #221
HumanOstrich wrote: post #155

Earlier quoted context omitted.

Libraries that automatically throw errors for status codes in the 400 and 500 ranges are pretty obnoxious (looking at you, axios). It adds unnecessary overhead, complexity, and bad ergonomics by hijacking control flow from the app. Responses with status codes in the 400 range are client errors, so the client shouldn't retry the same request. So a 404 is appropriate despite how annoying a library might be at handling…

Completely agree on the axios part - one implication of that is you can't statically type the error response shapes (since exceptions can't be typed). Where as with fetch you can have a discriminated union based on the status code (eg: https://github.com/mnahkies/openapi-code-generator/blob/main... ) Although I do feel like I've seen too many instances of a 404 being used for an empty collection where it would make m…

[deleted]

Re: I’ve banned query strings

#272

Post by em-bee »

masklinn wrote: post #203
em-bee wrote: post #151

Earlier quoted context omitted.

that's not what i meant. i was trying to suggest that the string "blob" does not fit. why is it there? why is it needed? https://github.com/gritzko/beagle/a7e17290a39250092055fcda5ae7015868dabdb4/VERBS.md this should be sufficient to represent the file. "blob" is like a descriptor of the value that follows. it would be like doing this: https://github.com/user/gritzko/project/beagle/blob/a7e17290a39250092055fcda5ae701…

> this should be sufficient to represent the file. Except it's not, because the oid can be a short hash ( https://github.com/gritzko/beagle/blob/a7e172/VERBS.md ) and that means you're at risk of colliding with every other top-level entry in the repository, so you're restricting the naming of those toplevel entries, for no reason. So namespacing git object lookups is perfectly sensible, and doing so with the type you…

how does adding the word blob in the url help with that?

i don't think it makes a difference here.

in fact compare these urls:

https://github.com/gritzko/beagle/blob/a7e172/VERBS.md

https://github.com/gritzko/beagle/raw/a7e172/VERBS.md

https://github.com/gritzko/beagle/commit/a7e172/VERBS.md

turns out that "blob", "raw" and "commit" have nothing to do with the hash itself, but are functions to describe how the object in question is to be presented. so what i said above about blob being redundant is false, the problem is rather that it is in a weird place. it should be at the end, like a kind of extension because it signifies the format of the output. except i think putting it at the end makes handling relative paths more difficult as it would have to be appended to every link to other files.

the roxen webserver has an interesting solution for that. they call it prestates and it's placed at the beginning of a url: https://github.com/(commit)/gritzko/beagle/a7e172/VERBS.md . it sets the format value visually apart, and you could have multiple prestate values separated by a comma. i have used that feature extensively on my own sites. i even expanded on the concept in custom modules.

Re: I’ve banned query strings

#273

Post by em-bee »

masklinn wrote: post #200
em-bee wrote: post #153

Earlier quoted context omitted.

actually, instead of the object hash, you could also use the commit-hash. then the filename would be mandatory, but the url would be more readable and usable: give me the file VERBS.md as it is at commit

That's actually what it is here, a7e17290a39250092055fcda5ae7015868dabdb4 is a commit's oid: https://github.com/gritzko/beagle/commit/a7e17290a3925009205...

yes, you are right. and it makes a lot more sense that way. see my other comment on the difference between commit blob and raw.

Re: I’ve banned query strings

#274

Post by [deleted] »

mystraline wrote: post #76
dredmorbius wrote: post #53

Earlier quoted context omitted.

Just straight "400" ("Bad Request") or "403" ("Forbidden") would also probably be defensible. Odd that there aren't any error response codes specific to URI parameters. Several options which seem like they might be appropriate aren't on close examination: - "406" ("Not Acceptable") which is based on content-negotiation headers. - "409" ("Conflict") which is largely for WebDAV requests. - Others such as 411, 422, and…

Just fire off a 200 OK with text body of "499 Bad query string" Im not making this up btw. A old NOC I woeked at emitted every error as 200 OK with the body message with the real error. They were a real shitshow.

[deleted]

Re: I’ve banned query strings

#277

Post by zymhan »

chrismorgan wrote: post #173
ollien wrote: post #37

Earlier quoted context omitted.

I don't think it's an abuse, RFC9110 defines 414 as a response for "refusing to service the request because the target URI is longer than the server is willing to interpret". Since adding a query string involves only adding characters, this seems fine; there's no stipulation as far as I can tell that all pages a server hosts must adhere to the same length. I'd be curious if any well-known clients interpret it that wa…

I reckon it is still an abuse. I am willing to interpret longer target URIs… so long as they don’t contain a question mark. /no-query-strings is longer than /?.

The standard doesn't say that you must accept all URIs up to a certain length. You're allowed to decide, based on context, what is "too long".

That is to say, you're allowed to have a double standard. And I love this sort of stuff, thanks for sharing.

Re: I’ve banned query strings

#278

Post by susam »

hamdingers wrote: post #264
susam wrote: post #213

Earlier quoted context omitted.

This corrupts a URL like: https://example.com/?p=20&utm_source=spam to: https://example.com/ when in fact we want the following: https://example.com/?p=20 A possible improvement can be: javascript:(()=>{const u=new URL(location.href);[...u.searchParams.keys()].forEach(k=>{if(k.startsWith('utm_')){u.searchParams.delete(k)}});navigator.clipboard.writeText(u.href)})();

We have different goals. I do this to strip unnecessary junk off of product page links I'm going to share, and your version now does nothing to (for example) Amazon PDP links. I understand it doesn't work for every kind of link and that's fine. If I did want to support paginated/search pages, I would allowlist only `p` and `q` rather than specifically blocking one type of analytics.

Yes, that's fair. Indeed my so called improvement requires continual maintenance to add new parameters to the blocklist, which somewhat defeats what is perhaps the main purpose: convenience.

While it is clear that your solution works well for you and would probably work for me too for most types of 'bad' URLs, I am noting down an allowlist based solution for my own satisfaction and future reference:

  javascript:(()=>{const u=new URL(location.href);[...u.searchParams.keys()].forEach(k=>{if(!['p','q'].includes(k)){u.searchParams.delete(k)}});navigator.clipboard.writeText(u.href)})();
Tested with the following URL:

  https://duckduckgo.com/?ia=web&origin=funnel_home_website&t=h_&q=hello+world&chip-select=search
The bookmarklet copies this cleaned version of the URL:

  https://duckduckgo.com/?q=hello+world

Re: I’ve banned query strings

#279

Post by TZubiri »

jedimastert wrote: post #269
TZubiri wrote: post #135

Earlier quoted context omitted.

Whatwg is for html, try the IEEE http rfcs

The IEEE rfcs does define a spot for the query string, but doesn't really say what to do with it. https://datatracker.ietf.org/doc/html/rfc3986#section-3.4

Try 1866 and 1867

Html is relevant historically as that syntax comes from forms. It was historically a sort of API between the browser client and the server, so yeah.

But it's pretty well defined since 1995

Re: I’ve banned query strings

#280

Post by cobbzilla »

stirfish wrote: post #255
cobbzilla wrote: post #234

Earlier quoted context omitted.

Which runs on what computer in 1995?

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); pr…

A post claimed CGI led to bad standards around query parameter formatting and parsing. I was merely pointing out that, prior to the advent of CGI, if you wanted to actually do anything with those parameters on the server, you had to extend whatever primitive HTTP server you were running, write some custom code and invent your own “standard”. There were no server side frameworks or standards.
Post reply on HN