Is there a limit to the length of a GET request? [duplicate]

I

6

162

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

Insolvable answered 5/11, 2008 at 19:40 Comment(2)

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. – Cony 28/10, 2016 at 11:35

how funny that this question is marked as a duplicate of a question asked after this question...... Even this question which has a more proper answer is asked after this question – Rhombus 28/5, 2018 at 17:36

D

80

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.

Demitasse answered 5/11, 2008 at 19:43 Comment(1)

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." tools.ietf.org/html/… – Colleencollege 16/11, 2011 at 2:4

S

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.

Scutter answered 5/11, 2008 at 19:44 Comment(10)

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. w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.3 – Unprepared 10/2, 2012 at 5:52

The purpose of URIs are not to define a RESTful API for the web. At all. w3.org/Provider/Style/URI.html – Scutter 10/2, 2012 at 11:22

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. – Unprepared 10/2, 2012 at 19:19

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 redrata.com/restful-uri-design – Scutter 16/2, 2012 at 11:42

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.". – Unprepared 17/2, 2012 at 0:2

"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 (tech.groups.yahoo.com/group/rest-discuss/message/6757) & (ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm) – Unprepared 17/2, 2012 at 0:3

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. – Unprepared 17/2, 2012 at 0:6

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. [ics.uci.edu/~fielding/pubs/dissertation/evaluation.htm#sec_6_1] – Scutter 17/2, 2012 at 14:54

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. – Scutter 18/2, 2012 at 13:36

Trying to make all URIs readable is just daft. – Refection 13/1, 2013 at 14:15

D

21

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.

Diallage answered 14/7, 2013 at 1:38 Comment(0)

C

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.

Chemise answered 5/11, 2008 at 19:46 Comment(4)

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. – Kane 15/3, 2012 at 8:59

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. – Diallage 30/7, 2012 at 18:58

This MS KB article states IE8's (and earlier) URL limit for GET and POST URLs is 2083 chars: support.microsoft.com/kb/208427 – Josephus 30/10, 2012 at 23:49

@Diallage Your comment should be an answer so people will see it and I can up vote it. Thanks for the testing. – Oller 11/7, 2013 at 16:15

S

12

W3C unequivocally disclaimed this as a myth here

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

South answered 9/12, 2011 at 16:59 Comment(3)

It’s about a myth of a specific limit of 256 characters, and there is a provable limit in IE. – Bookseller 22/11, 2012 at 9:31

The link is superseded by w3.org/2001/tag/doc/whenToUseGet-20030922#ephemeral (which says the same thing) – Canada 17/9, 2013 at 10:24

@JonasKölker l e€33#SDay s – Diallage 15/7, 2016 at 14:1

C

1

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

Cognation answered 5/1, 2012 at 16:41 Comment(1)

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. – Noodle 26/3, 2015 at 9:18

Recommended topics

Hot tags