

What is the maximum length of a URL? - wslh
http://stackoverflow.com/questions/417142/what-is-the-maximum-length-of-a-url

======
ojiikun
No matter how long you think they can get, take care if you are going thru a
load balancer - many, (those by Citrix come to mind) can mysteriously truncate
URLs and cause all manner of weird bugs.

And, of course, insert here a long-winded rant about how broken your data
model is if you need more than about 1000 chars. ;)

~~~
afandian
What about lots of GET params? Doesn't seem like lots of those means you have
a broken data model.

~~~
mistercow
I think if you have nearly 1KB of GET data, something is definitely wrong.

~~~
waitwhat
1KB of GET data is ~25 UUIDs. That doesn't seem excessive.

~~~
mistercow
That seems like a lot of UUIDs to be passing via GET. If you send your UUIDs
in base 64, you can fit 125 into 1KB.

~~~
mnarayan01
Even 125 is not all that much if the resources are not being directly shown to
the user (e.g. automated services, etc).

~~~
mistercow
I'm trying to understand why you wouldn't use POST in that case.

~~~
fusiongyro
The choice between GET and POST should be driven by whether you're reading or
modifying the resource, not the size of the request.

~~~
mistercow
That's fine as an ideal, but can you give a non-aesthetic reason that it would
actually matter? I can understand that for some APIs, it's cool that a human
can read and edit the GET requests by hand and debug that way, but if we're
talking about requests that pass around more than fifty UUIDs at a go, I don't
think that's going to be a helpful approach anyway, and I'm really wondering
if it isn't pushing the limits of a RESTful API to begin with.

~~~
fusiongyro
Sure. All the proxies between you and the client are a lot more likely to
cache a GET than a POST.

~~~
mistercow
I've never looked at the code for caching GET requests, but I am going to go
out on a limb and say that that code is probably not optimized for keying on
1KB URLs. In fact, caching seems like a really good consideration regarding
the original point about 1KB being too big for a GET request in terms of
architecture design.

~~~
fusiongyro
You're really going to continue the debate by basically saying "I haven't read
the code but it must not work like that?"

In Squid it's 4K _by default_ : [http://www.squid-cache.org/mail-
archive/squid-users/200208/0...](http://www.squid-cache.org/mail-
archive/squid-users/200208/0423.html)

I see no reference to a maximum URL size in Varnish, and a cursory glance
through the source code is not revealing a hard-coded size. I'm not shocked.
PHK is well-known for writing good code and good code generally doesn't have a
lot of magic numbers.

I really can't stand contrafactual arguing from first principles. I gave you a
legitimate non-aesthetic reason and you came back with a softly wilted notion
conjured whole out of your imagination. Shut up already.

------
bmuon
Many comments seem to focus on traditional GET requests in which case long
URLs are usually a smell. But there's a rather new requirement in the web that
conflicts with limits on URL length: the use of modules for front-end
JavaScript code. The best practice for modules is usually expressed as:

1) Write small modules 2) Concatenate scripts

If you try to automate module concatenation then you'll get URLs like
[http://example.com/combo?foo.js&bar.js&baz.js](http://example.com/combo?foo.js&bar.js&baz.js),
which combined with "write small modules" can mean a long list of small
modules that easily reaches 2000 characters.

~~~
grncdr
What is the use case for concatenating scripts on request rather than as a
build step?

~~~
jap
One use case is if the scripts are part of a large framework on a 3rd party
server. See e.g. the YUI 3 library configurator:
<http://yuilibrary.com/yui/configurator/>

------
gcb0
It all boils down to the server/client. as in: does it matter if the http spec
says X if the most used browser only sends X/2?

back in 90-something i had to research that for url and cookies.

msdn specs said something like "[url|cookies] should be at least [some size]"

mozilla's and w3c specs said: "[url|cookies] should be at most [some size]"

for everything. url lenght. cookie lenght. number of cookies per domain.
number of cookies per subdomain... it was like that for ALL items. one said
'at least' the other 'at most', and for added fun, all the values where
exactly the same on both.

~~~
jacques_chester
The thing is that the RFCs use MAY and SHOULD for these things. Not MUST or
SHALL. So it's implementation-defined from the get-go.

I presume that the people writing HTTP servers and clients usually found it
easier to allocate a fixed-length char array.

~~~
gcb0
May vs Should i can take. but At least vs At most I sincerely can't.

------
adamauckland
What about a RESTful API where you pass in a list of IDs to retrieve from the
server? You'd want to use a GET so it's idempotent but I can't see how you'd
make an exceedingly long list of IDs without using a data payload underneath
the GET statement.

~~~
darrhiggs
Don't do it that way then. How about a using /queries collection? You could
create a query there and have the server return a link to the results using
the 'location' header.

~~~
mnarayan01
Or you could just use a PUT request with the ids in the request body. I get
the reasoning behind doing it with a POST -> GET, but doing that as a default
case would be nuts. If nothing else either I can a) DOS you trivially or b)
you might as well use PUT because the result URI is going to be far from
permanent.

~~~
adamauckland
This is probably the most correct response. It still bothers me that because
GET can't take bulk parameters I either have to use a PUT or spool many GETs
(which still isn't as fast as one GET)

------
ry0ohki
Another practical limit, I tried to register a 60ish character URL, and
neither GoDaddy nor NameCheap would allow it.

~~~
bodhi
In case you were curious, from Wikipedia[1]:

> Each label may contain up to 63 characters. The full domain name may not
> exceed a total length of 253 characters in its external dotted-label
> specification.

In this context "label" means a segment of the name, so in "www.example.com."
"www", "example", and "com" are all labels.

The next sentence:

> In practice, some domain registries may have shorter limits.

alludes to your problem somewhat ;)

[1]: <http://en.wikipedia.org/wiki/Domain_Name_System>

------
skwosh
Other applications of long URLs:

\- Unique and unforgeable references for capability-based security (e.g. the
Waterken Server)

\- Serialized continuations, or unforgeable references to server-side
continuations (as in continuation-based web servers)

------
lucb1e
I still think you should try not to exceed 255 characters, at least for the
part before the hash sign. A good URL should not change, and anything this
large is almost bound to change rather soon.

The data URI scheme does not really apply here since it's never sent to any
server. If a browser understands data URIs, it should logically also allow
such long URLs.

~~~
Frozenlock
I use long URL _because_ I want unique URL that will never change.

Specifying what item(s) should be targeted in a pool of possibly millions,
with endless possible combinations is bound to require some kind of precise
pointer.

Here is an example URL I use:
[https://bacnethelp.com/vis/overview/KHs6cHJvamVjdC1pZCAiNTA1...](https://bacnethelp.com/vis/overview/KHs6cHJvamVjdC1pZCAiNTA1YTEyNWU0NGFlNDJlMDVhNzUwYzk3IiwgOm9iamVjdC1pbnN0YW5jZSAiMiIsIDpvYmplY3QtdHlwZSAiMCIsIDpkZXZpY2UtaWQgIjEyMzQifSB7OnByb2plY3QtaWQgIjUwNWExMjVlNDRhZTQyZTA1YTc1MGM5NyIsIDpvYmplY3QtaW5zdGFuY2UgIjEiLCA6b2JqZWN0LXR5cGUgIjAiLCA6ZGV2aWNlLWlkICIxMjM0In0gezpwcm9qZWN0LWlkICI1MDVhMTI1ZTQ0YWU0MmUwNWE3NTBjOTciLCA6b2JqZWN0LWluc3RhbmNlICIwIiwgOm9iamVjdC10eXBlICIwIiwgOmRldmljZS1pZCAiMTIzNCJ9KQ.).

What I could do, however, is use some kind of shortening url scheme, kinda
like google maps: <http://goo.gl/maps/3uP8y>.

I'm still uncertain about which way is better.

EDIT: Of course I mean a local shortening url, pointing to my own databases.

~~~
dorianj
In the example URL you gave, the content of the URL (base64): ({:project-id
"505a125e44ae42e05a750c97", :object-instance "2", :object-type "0", :device-id
"1234"} {:project-id "505a125e44ae42e05a750c97", :object-instance "1",
:object-type "0", :device-id "1234"} {:project-id "505a125e44ae42e05a750c97",
:object-instance "0", :object-type "0", :device-id "1234"})

seems like it would be better stored on the server in redis or something (or,
at least if leaving it in the URL, a more compact deduplicated format might be
worthwhile)

~~~
mnarayan01
Part of me wonders what would happen if someone where to Base64 encode
something like

    
    
      ({:project-id {:conditions "true); DELETE FROM projects WHERE (true"}})

~~~
Frozenlock
Nothing, it's not sql. It's a clojure map with all the necessary info to find
the different components.

But nice reflex! ;-)

------
asiermarques
Depends on your web server configuration
[http://httpd.apache.org/docs/2.2/mod/core.html#limitrequestl...](http://httpd.apache.org/docs/2.2/mod/core.html#limitrequestline)

------
jpswade
As of 2012, they are as long as the platform will support because of the Data
URI scheme.

~~~
cek
The title of the post & the underlying SO article discuss URLs. A data: URI is
not a URL, but a URI.

People get confused about this all the time, but a URI is not necessarily a
URL. A URL is always a URI. A URN is also a URI and might be a URL as well.[0]

Interesting side note is how, in 1997, with the original uuid: draft[1] I
goofed and didn't recognize uuid: was really a URN. This was corrected in RFC
4122 in 2005[2].

[0] <http://en.wikipedia.org/wiki/Uniform_resource_identifier> [1]
<http://tools.ietf.org/html/draft-kindel-uuid-uri-00> [2]
<http://www.ietf.org/rfc/rfc4122.txt>

~~~
jpswade
The data URI scheme is defined in RFC 2397.

See: <http://tools.ietf.org/html/rfc2397>

Entitled as 'The "data" URL scheme'.

Either way, it doesn't matter, because the OP has provided such limited
details as to why this is required knowledge that the question is as
irrelevant as the accepted answer.

------
martinced
If you control both the client and the server you can have quite long URLs.

I don't agree that a long URLs necessarily indicates a broken design. I've
done it and configure my web server (Tomcat) to accept longer GET requests (so
+1 to 'asiermarques' here, who pointed out that it depends on how the web
server is configured too).

There are services out there, like Google Charts if I'm not mistaken (but I
may be mistaking it with something else) which, by the way they work, forces
you to create quite long URLs. It generates a graph on the fly and nothing is
modified on the server, so a GET is used, not a POST (which, IMHO, makes
sense).

From the thread I seem to understand that the Data URI scheme implies that
company should start to upgrade or replace their broken load balancer that
"mysteriously" truncate URLs and cause all manner of weird bugs ; )

~~~
danielweber
_If you control both the client and the server_

. . . and all proxies that may be in-between.

I've debugged more than one client issue where people were doing something
really weird over port 80.

