The URL length limit seems pretty reasonable, especially since the URL is a highly user visible component, so overly long URLs annoy/harm users much more than web devs (just think of pasting this super-long url into chat or company wiki!)

In particular, I think the URL should be copy-pasteable at all times, and according to your google's link, that means 32KB limit. I'd lower it to 8 KB just to be safe in case there is URL encoding involved.

If you're implementing a web server you would want to allocate a fixed size buffer that can hold the request body or at least the request headers. Otherwise an attacker can cause excessive reallocations (memory churn) just by sending very long requests, and hold the memory until you time out their connection.

There's no good reason for absurdly long URL's to exist in the first place.

URL's are meant for human consumption and use -- to be copied and pasted, to fit in a message, to be typed in. They're analogous to phone numbers and addresses.

They're meant to be a pointer, a location, an index. Not a data payload. That's what POST variables are for.

No, web browsers shouldn't introduce an arbitrary limit to URL lengths. But for web hosts, it's entirely reasonable.

I mean, what, do you think filenames or filepaths should be 2 MB as well? That's absurd. But URL's are basically just the filenames of the internet.

Maybe it is, maybe it isn't.

The nature of the web is changing, and has changed. Since GET requests can't have `body` data, if you have any hope of passing information along to a GET request, you must encode it in the URL in some way. This can be particularly important for things that contain unique but repeatable parameters that augment what you see on first load that would only be known by the consumer, and then can be shared by URL. For example, options set on a table you want to share with those options intact.

For which something like a 4 KB limit is more than enough, like options on a table.

The point is, once you switch from options to actual data, you switch from GET to POST. This is not a bug, this is a feature. POST is for posting data. GET is for retrieving it only, not for sending it.

More than enough in your opinion. It is perhaps your use case that 4KB works completely fine for, but this is not everyones.

We have a fairly complex set of options users can filter through (by design, and prior to its implementation, by high % of requests by users, FWIW) that need to be sharable on the GET request, they are definitely at least 12KB, likely more.

But that's far too large to easily share in things like plaintext emails or text messages.

If you're unable to compress it further, why don't you implement a TinyURL-type scheme? Save the options on your backend and give them a pointer to the settings. And it can expire after 30d or 1y or never.

Then it actually becomes the size of something shareable.

URLs are resource locators. You're not locating a resource, you're passing a gigantic configuration payload.

This is true, but it is the most efficient way that doesn’t induce complexity like having to serialize every option chosen to the backend immediately. Knowing we can re-create everything in first request is much more simple than other methods and doesn’t require the end user to get a special link generated for sharing they can just share straight for the URL bar.

Well there's certainly nothing that strictly prevents GETs from having a body other than no guarantee that all client libraries will handle them. I've seen a mix that allow it and disallow it. What is common is the libraries that don't support it don't seem to have any indication of this and from what I remember are likely to fail silently. Fairly annoying, so it makes sense why this is basically never used.

> Since GET requests aren't suppose to have `body` data, if you have any hope of passing information along to a GET request, you must encode it in the URL in some way.

Or in the request headers.

To be clear, I misspoke, I should have put effectively GET requests really can't have body data. Headers have the same problem. You can't possibly encode it without encoding it in the URL anyway

Why have parameters at all if they're not meant to be used? I don't really buy the argument that you're allowed to use parameters for small things but not for large things. Personally, I prefer if sites give me a local-only option of storing my data and sharing it with others.

OTOH, they both are part of the message, the url having a more wasteful encoding. So it wouldn't matter that much, unless Vercel has a reason to store the URL in memory?

No, because the URL is not the message, it's the address. Per the acronym, it's the locator only. It's not for data.

URL's get stored in logs, analytics, and so forth, where they're expected to be short.

Payloads don't. So you put the payload part in the payload, not the address.

URL processing is the `/bin/sh` of browsers. You can stuff anything in there, even JavaScript, and it’ll mostly work across browsers long as you adhere to the syntax.

Should it be? Probably not, but it’s a nice-to-have if you need to do something quick and dirty.

I'm happy with Vercel's restrictions, especially considering I'm only using their very generous free tier.

The biggest practical reason I can think of is directly relevant to their free tier: they cache heavily, that's not quite the whole point of the platform but it's a large part of its appeal to me. They're obviously not going to be able to cache everything even with a limit as low as 14kB, but they're happy-pathing projects that are at least vaguely amenable to caching.

In the meantime, I get to throw code at them and not care about where or how they execute it, and I really like that.

I don't find 14kb to be an unreasonable limit for URLs.

While I have a sibling comment to yours saying I'm quite happy with the imposition of the limit, in my day job I frequently find code that pushes the boundaries of "reasonable" and I'm fairly sure we will exceed 14kB. But we don't use Vercel at work, so it's fine.

I suspect that while it's a reasonable limit for them, it probably won't work very well to impose a limit on an established code base that's not been built with a limit in mind.

Agreed. Cloudflare limits URLs to 16KB, AWS ALBs are also 16KB, so 14KB doesn’t seem out of place.