Hacker News new | ask | show | jobs
by verelo 2661 days ago
I get why that's "yuck" but if I'd hedge a bet...it's probably done because it's easier to make a GET than it is a POST or PUT request and the length of a text message will never exceed the query string uri length limits.

Not saying I disagree, but i don't know it changes a whole lot in this case.
4 comments
beager 2661 days ago
In this case maybe, but generally GET should be avoided for any creative/transactional action because many systems will replay/cache GET requests, assuming that they’re idempotent.
link
verelo 2661 days ago
Yeah the caching issue is a great reason not to use a GET, i was more just suggesting if you're being lazy and pasting a request into a browser v's using a command line (which obviously you should) then it's easy to get going quickly to kick the tires.
link
eridius 2661 days ago
If you really want to, you can in fact issue a POST with a query string and no body. It would admittedly be rather unusual.

Also, application/x-www-form-urlencoded bodies are literally identical to query strings anyway, so if you can construct a query string, you can easily construct a POST body using that Content-Type too.

link
cortesoft 2661 days ago
How is a GET request easier? I assume you need to include authentication somehow, so it isn't like you are triggering it by typing the url in a browser.
link
Groxx 2661 days ago
just to point out: there are no uri length limits. browsers typically have one (I haven't checked lately tho), but other tools generally don't (except by mistake / size-capped buffers).
link
asddgsgsaxg 2661 days ago
Not sure why you believe this so strongly, but every single HTTP client impose some limit.

Modern browsers are typically around 100-200k limit, command line tools such as curl and wget also has their limits.

IE was famously limiting GET requests to about 2k bytes.

link
Groxx 2660 days ago
the spec does not define a limit, and the widely varying implementation-specific limits are soft evidence of that.

even wget and curl are probably more limited by your CLI arg length limits than the bins themselves. e.g. I can craft a multi-megabyte GET request in a file and pass it to `curl -K` and it works just fine (I just did so to verify, a bit over 3MB. google complained a bit, but it responded). even if I screwed that up somehow / it silently truncated, I can absolutely do something with netcat and know it won't truncate.

link