Is there a limit to the length of a GET request?

Question

This question was closed on basis there is similar question in SO, but the other question was asked 2 years later. Hence this can't be a duplicate. — user902383, Oct 28 '16 at 11:35
how funny that this question is marked as a duplicate of [a question asked after this question](https://stackoverflow.com/questions/2659952/maximum-length-of-http-get-request)...... Even this question which has a more proper answer is asked after [this question](https://stackoverflow.com/questions/417142/what-is-the-maximum-length-of-a-url-in-different-browsers/) — Jun, May 28 '18 at 17:36

score 80 · Answer 1 · answered Nov 05 '08 at 19:43

Not in the RFC, no, but there are practical limits.

The HTTP protocol does not place any a priori limit on the length of a URI. Servers MUST be able to handle the URI of any resource they serve, and SHOULD be able to handle URIs of unbounded length if they provide GET-based forms that could generate such URIs. A server SHOULD return 414 (Request-URI Too Long) status if a URI is longer than the server can handle (see section 10.4.15).

Note: Servers should be cautious about depending on URI lengths above 255 bytes, because some older client or proxy implementations may not properly support these lengths.

HTTPbis adds a bit to this: "Various ad-hoc limitations on request-target length are found in practice. It is RECOMMENDED that all HTTP senders and recipients support request-target lengths of 8000 or more octets." http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-17#section-3.1.1.2 — Mark Nottingham, Nov 16 '11 at 02:04

score 56 · Answer 2 · edited Jan 30 '21 at 12:46

56

This article sums it up pretty well

Summary: It's implementation dependent, as there is no specified limit in the RFC. It'd be safe to use up to 2000 characters (IE's limit.) If you are anywhere near this length, you should make sure you really need URIs that long, maybe an alternative design could get around that.

URIs should be readable, even when used to send data.

edited Jan 30 '21 at 12:46

Cody Gray - on strike

239,200
50
490
574

answered Nov 05 '08 at 19:44

Vinko Vrsalovic

330,807
53
334
373

13

Good writeup, but URI readability has nothing to do with GET vs POST. The purpose is to define a RESTful API for the web that differentiates between the functional differences of request types. HTTP GET requests may tend to be user readable for hyperlinks, but that's not their purpose, just one use. http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.3 – DougW Feb 10 '12 at 05:52
3

The purpose of URIs are not to define a RESTful API for the web. At all. http://www.w3.org/Provider/Style/URI.html – Vinko Vrsalovic Feb 10 '12 at 11:22
3

Correct. The purpose of GET & POST however, is. The question is asking about HTTP GET requests. You're assuming he means hyperlinks found on a website, intended for human readability. That's one particular usage of GET HTTP, but far from the only one. – DougW Feb 10 '12 at 19:19
2

Nope, that's not the *purpose* of GET & POST. The REST architecture was invented long after the invention of the GET and POST methods of HTTP. Also, even when doing a REST app I'd argue strongly in favor of having, whenever possible, readable URIs. See http://redrata.com/restful-uri-design/ – Vinko Vrsalovic Feb 16 '12 at 11:42
4

Sorry but you're simply misinformed here. REST was concieved to describe the HTTP protocol, so while the term itself may post-date GET & POST, it exists solely to describe what they're for and what they do. I've got to appeal to authority here, because you're not arguing with me on this, you're arguing with Roy Fielding who *wrote* the HTTP spec and invented "REST". Again, the article you linked is concerned with human-readable URIs, which represents a small fraction of HTTP usage: "Short (as possible). *This makes them easy to write down or spell or remember*.". – DougW Feb 17 '12 at 00:02
"HTTP/1.1 is a specific architecture that, to the extent I succeeded in applying REST-based design, allows people to deploy RESTful network-based applications in a mostly efficient way, within the constraints imposed by legacy implementations" - Roy Fielding (http://tech.groups.yahoo.com/group/rest-discuss/message/6757) & (http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm) – DougW Feb 17 '12 at 00:03
1

Btw, I'm not arguing against short URIs. That's fine. But using POST just because your URI is too long is technically a misuse of POST. – DougW Feb 17 '12 at 00:06
4

I'm not arguing with Roy Fielding, I'm arguing with your interpretation of what Fielding says. In fact, you are interpreting the quote backwards, he's saying that HTTP/1.1 allows people to do REST the best way, not that HTTP/1.1's purpose is to do REST. I really don't see where he says that reason for the methods' existence (this is, their purpose) is to fit within a RESTful architecture. He says that if your application matches the scenario where REST makes sense, you should use it to get an optimum behavior. [http://www.ics.uci.edu/~fielding/pubs/dissertation/evaluation.htm#sec_6_1] – Vinko Vrsalovic Feb 17 '12 at 14:54
2

BTW, I would also argue that if you are using REST and the URIs used in GET requests are very long, you are probably doing something wrong. If you are sure of what you are doing, do use long URIs, but still try to make them readable. That will make the life of future developers easier. I guess that, in the end, all I'm trying to say is "if your URI are long, double check them and please try to make them readable". That is not at all opposed to REST. Although I agree that if you are using REST, changing GET for POST is always wrong. But if you are not, it's not necessarily wrong. – Vinko Vrsalovic Feb 18 '12 at 13:36
1

Trying to make all URIs readable is just daft. – Relaxing In Cyprus Jan 13 '13 at 14:15

score 20 · Answer 3 · answered Jul 14 '13 at 01:38

As Requested By User Erickson, I Post My comment As Answer:

I have done some more testing with IE8, IE9, FF14, Opera11, Chrome20 and Tomcat 6.0.32 (fresh installation), Jersey 1.13 on the server side. I used the jQuery function $.getJson and JSONP. Results: All Browsers allowed up to around 5400 chars. FF and IE9 did up to around 6200 chars. Everything above returned "400 Bad request". I did not further investigate what was responsible for the 400. I was fine with the maximum I found, because I needed around 2000 chars in my case.

score 17 · Answer 4 · answered Nov 05 '08 at 19:46

17

The specification does not limit the length of an HTTP Get request but the different browsers implement their own limitations. For example Internet Explorer has a limitation implemented at 2083 characters.

answered Nov 05 '08 at 19:46

Joakim Karlsson

1,112
1
15
27

1

Thanks for your accurate value => +1. However what is the specific version of IE? My IE8 does not accept more than 2048 characters on the address bar (URL entry box). But my JavaScript code can send XMLHttpRequest GET using 3586 characters (I did not test more). Therefore, where have you found 2083? Cheers. – oHo Mar 15 '12 at 08:59
10

I have done some more testing with IE8, IE9, FF14, Opera11, Chrome20 and Tomcat 6.0.32 (fresh installation), Jersey 1.13 on the server side. I used the jQuery function $.getJson and JSONP. Results: All Browsers allowed up to around 5400 chars. FF and IE9 did up to around 6200 chars. Everything above returned "400 Bad request". I did not further investigate what was responsible for the 400. I was fine with the maximum I found, because I needed around 2000 chars in my case. – OneWorld Jul 30 '12 at 18:58
This MS KB article states IE8's (and earlier) URL limit for GET and POST URLs is 2083 chars: http://support.microsoft.com/kb/208427 – Kevin Hooke Oct 30 '12 at 23:49
1

@OneWorld Your comment should be an answer so people will see it and I can up vote it. Thanks for the testing. – erickson Jul 11 '13 at 16:15

score 12 · Answer 5 · answered Dec 09 '11 at 16:59

12

W3C unequivocally disclaimed this as a myth here

http://www.w3.org/2001/tag/doc/get7#myths

answered Dec 09 '11 at 16:59

Oluwabusayo

193
1
8

3

It’s about a myth of a specific limit of 256 characters, and there is a provable limit in IE. – Jukka K. Korpela Nov 22 '12 at 09:31
3

The link is superseded by http://www.w3.org/2001/tag/doc/whenToUseGet-20030922#ephemeral (which says the same thing) – Jonas Kölker Sep 17 '13 at 10:24
@JonasKölker l e€33#SDay s – OneWorld Jul 15 '16 at 14:01

score 1 · Answer 6 · answered Jan 05 '12 at 16:41

1

setFixedLengthStreamingMode(int) with contentLength parameters could set the fixed length of a HTTP request body.

answered Jan 05 '12 at 16:41

wurde

2,487
2
20
39

This seems to be the only answer that is actually relevent. The others are all about URL lengths, which doesn't appear in the question. – user207421 Mar 26 '15 at 09:18

Is there a limit to the length of a GET request?

6 Answers6

Linked