JWSmythe's Journal: Things I learned today. Browser URL length limitations

For a long time, I've followed what I've read regarding URL lengths. 255 characters is it. Never let it get longer than that.

    By the RFC's, 255 characters is the guideline, to maintain backward compatibility with old browsers, old proxy servers, and other miscellaneous hardware that may be in the way.

    I went looking for more information, but found conflicting or outdated information. Who cares what the limits on Netscape 4 or MSIE 5 were.

    In my own personal MythBusters kind of way, I wanted to see what the limitations really are.

    What fun would it be without coding something up to handle it. :) I would share the code, but it seems Slashdot doesn't like that much. Basically, it would generate a URL, something like http://example.com/test.php?pad=11111 , and use a javascript redirect to send it back to itself. On receiving it, it would read the number of characters of the full URL, then add an increment to the pad. It printed the length of the request, and the full URL in the browser, so I could see where it was at. I introduced a 1 second pause so I could read the output.

    Initially my increment was 1, but that takes an awful long time, even with keepalives cranked up. I worked my way up to 500 per exchange, so the test would move along quickly. Watching the server stats, the keepalives were doing their job perfectly. The same connections were reused until their life expectancy ran out.

    I couldn't just give a redirect header. Browsers tend to not like that. My initial test with Firefox showed the problem. The default for network.http.redirection-limit is 20. Even turning that up to 999999 would stop pretty quickly (at about 500, if I remember right)

    My test client machine is a Windows 7 Ultimate machine with a Phenom II x4 955 and 8GB RAM. My test browsers are MSIE 8.0, Chrome 9.0, Firefox 3.6.13, and Safari 5.0.3. During the tests, I did not run into problems with CPU or memory utilization.

    My test server is a Slackware Linux 13.1.0 machine with two dual core Xeon 2.8Ghz CPUs and 4GB RAM. It is using Apache 2.2.17 and PHP 5.3.5. Other than custom configuration options, it's a fairly plain version of Apache and PHP. No patches. The OS is pretty clean. All non-essential ports and tasks are disabled. During the test, I did not run into any CPU or memory utilization problems.

    On the first run I observed:

        MSIE 8.0 4095
        Chrome 9.0 8190
        Firefox 3.6.13 8190
        Opera 11.01 8190
        Safari 5.0.3 8190

    I looked around a little. Apache lets you lower the length of the URL in the config file, but not increase it. The default is 8190, exactly as tested. Time to go patch Apache!

In httpd.h
/** default limit on bytes in Request-Line (Method+URI+HTTP-version) */
#ifndef DEFAULT_LIMIT_REQUEST_LINE
#define DEFAULT_LIMIT_REQUEST_LINE 16777216
#endif /** default limit on bytes in any one header field */
#ifndef DEFAULT_LIMIT_REQUEST_FIELDSIZE
#define DEFAULT_LIMIT_REQUEST_FIELDSIZE 16777216
#endif /** default limit on number of request header fields */
#ifndef DEFAULT_LIMIT_REQUEST_FIELDS
#define DEFAULT_LIMIT_REQUEST_FIELDS 16777216
#endif

    8190 was obviously set by people with no ambition. 16.7 million? That's a real URL! :) And before anyone says it, no, I wouldn't normally make the URL longer than I'm willing to type. Just like the MythBuster folks wouldn't normally put a dead pig in a car to see if it stinks. It's all in the name of science I tell you! :)

    So limits upped to 2^24, recompile complete, and we're ready to test again. While watching the compile, I had to ask myself, "does PHP have a limit too?". I guess not. Here's the results.

        MSIE 8.0 4095
        Chrome 9.0 122560
        Firefox 3.6.13 111060
        Opera 11.01 132560
        Safari 5.0.3 131060

Notes:
    1) I aborted the tests after I got bored.

    2) Chrome stopped displaying the full URL at about 32,000 characters. It truncated it at the ?, but did process correctly. If you have a 32,000 character URL, expect people to not be able to copy it from Chrome very easily. :)

    3) I started all the tests very close to the same time, and aborted them all very close to the same time. I don't normally use anything but Firefox, so I have several utility toolbars (webmastering, packet examination, and SEO analysis) that are installed. The others are clean.

    4) You can't use this as a benchmark saying any browser is faster than another, because I was limited by upload bandwidth at home.

    During the test, I was watching my uplink bandwidth graph. I'm on a residential line. It was clear where the upload bandwidth is cut off at (about 700Kbps). Due to the nature of this test, Every request was sent to the server, and returned to the browser, so like it or not I needed to use the same bandwidth each way. If I have a moment of sheer boredom at work or a datacenter sometime, I may repeat this test on a LAN. It's doubtful though.

    So in conclusion....

    1) All the modern browsers tested, except MSIE are effectively unlimited to the size of the URL they can handle.

    2) MSIE is still limited to a URL length of 4095 characters. I don't see a workaround for this.

    3) Apache is limited by default to 8190 characters, but this can be corrected with a patch.

    4) Regardless of what these components proved they could do, you can still encounter problems with firewalls, content filters, proxy servers, etc. Don't expect to be able to use over 255 characters.

Re:

[JWSmythe]

Oh, of course, POST works. :) Well, there are limitations, but they're usually serve imposed. For example, for post_max_size upload_max_filesize in php.ini. When you put files up somewhere via a web form, it's by POST.

I've used POST for almost everything I've done for years. The only exception is when I want to give people a good way to bookmark a specific page, or to make it easier on search engines. Those are the only legitimate reasons I can think of to use GET.