This question already has answers here:
Maximum length of HTTP GET request
(7 answers)
Closed 6 years ago.
Is there a limit to the length of a GET request?
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.
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.
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.
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.
W3C unequivocally disclaimed this as a myth here
http://www.w3.org/2001/tag/doc/get7#myths
setFixedLengthStreamingMode(int) with contentLength parameters could set the fixed length of a HTTP request body.
Related
My url is as follows
/fcgi-bin/clireports.fcgi?sfPageId=param1&sfBoxId=param2&sfPagecId=param3&sfUsername=param4&sfSession=param5&sfSubmit=param6&showSampleReport=param7&saveAndAdd=param8
My questions is this:
Is there any performance issue when sending so many parameters in the query string ? In my case I am sending 8 parameters in the query string .
Will my website become slow because of this ?
Please enlighten me on this .
The performance is not about number of parameters (or just a little) but about number of bytes send.
The more data you send, the more it's costly to transfer/parse.
Remember that every browser has a hard limit on the maximum number of characters a GET request can handle. I recomment you not to use more than 255 characters to be on the safe side, but you can go higher (IE's limit is around 2000).
If you need more data, use POST.
Finally, your website will not become slow because of this. Because many other factors take much time than parsing GET request (take something like DB connection, or just php warmup)
Shouldn't be any issues, might be worth doing a POST request to clean up your request a bit, but other than that you shouldn't notice any issues as far as performance...just don't exceed the "limits" that vary depending on browser
I am making an API call to Facebook, using the Facebook C# SDK, and I can't seem to send long query strings via HTTP GET. I need a long FQL query (select .. from .. where .. in ) to execute and I can't seem to send it. If the query is smaller, it does send successfully and return the results. Unfortunatelly, as FQL supports GET and not POST, I am stuck to GET.
How can I increase the default query string limit in Windows Phone HttpWebRequest?
I am using Windows Phone SDK 7.1, but testing on Windows Phone 8 device.
It seems you need to switch to http post (if possible) or optimize your request somehow.
Read What is the maximum length of a URL in different browsers?. While the official standard for HTTP says that there should be no maximum, in reality there are maximums. For example, IE have an upper bound of 2083 characters. Windows Phone seems to have similar limit to IE.
Microsoft Internet Explorer has a maximum uniform resource locator
(URL) length of 2,083 characters. Internet Explorer also has a maximum
path length of 2,048 characters. This limit applies to both POST
request and GET request URLs.
If you are using the GET method, you are limited to a maximum of 2,048
characters, minus the number of characters in the actual path.
However, the POST method is not limited by the size of the URL for
submitting name/value pairs. These pairs are transferred in the header
and not in the URL.
RFC 2616, "Hypertext Transfer Protocol -- HTTP/1.1," does not specify
any requirement for URL length.
Source: http://social.msdn.microsoft.com/Forums/en-US/wpdevelop/thread/f96622fe-4dcb-4d38-8831-4cfad1aa4a06/
I know how HTTP methods work and for what they are designed, but I'm curious to know if some methods are faster than others when using just to get data.
In the team I'm working on I noticed a lot of JQuery ajax requests like this below:
$.ajax({url: "../dir/someFile.json", method: 'post', dataType: 'json',
error: function(...){ ... },
success: function(...){ ... }
});
I'd obviously use a 'get' method, as no data is sent to this request. This probably happened when a teammate was copying and pasting code. This works fine also, seems there's no good reason for changing it to 'get'.
I think using 'get' method would be faster in this case, but I didn't find any source affirming that.
There is some research that shows that some browsers will divide a POST request into multiple packets. This could have a performance impact, which you'd think would make the request slower. But, under tests it seems that POST can sometimes be faster. I'm not sure why this is.
In practice however, the performance difference is negligible and you should use POST and GET as intended.
Read:
http://loadimpact.com/blog/ajax-get-or-post-which-is-best
http://developer.yahoo.com/performance/rules.html#ajax_get
http://thinkvitamin.com/code/the-definitive-guide-to-get-vs-post/
At least with historical versions of IE, there is the issue of POST transferring an extra packet. Some discussion of this here:
http://josephscott.org/archives/2009/08/xmlhttprequest-xhr-uses-multiple-packets-for-http-post/
I don't know how relevant this is with the current crop of browsers, though.
Here are the results of the tests described in the article:
IE 6 – 2 packets
IE 7 – 2 packets
IE 8 – 2 packets
Firefox 3.0.13 – 1 packet
Firefox 3.5.2 – 1 packet
Opera 9.27 – 2 packets
Safari 4.0.3 – 2 packets
Chrome 2.0.172.43 – 2 packets
It might seem obvious, but when using POST versus GET, you're using one more byte in the method name.
In addition, if you have (few) data to send, using GET will URL-encode the data (this means that the number of generated & sent bytes will be higher than the data size itself) while POST will consume more byte (in general) because the request will additionally contain a Content-Type: application/x-www-form-urlencoded header, likely a Content-Length header plus the same URL-encoded data as GET.
If you have some binary data to send, the question does not hold since you can't do that with GET.
We are speaking of pennies here, but if you accumulate pennies...
In the end, the GET request will be shorter and, for the same network link bandwidth, will be faster than POST.
To send binary data, PUT will be faster than POST (based on the same logic, and because POST will use multipart/form-data encoding headers), but browser support is more limited for PUT requests.
All things being equal, there is no difference in network performance between GET, POST, or any of the other methods. It all depends on how the server handles a GET vs. POST request. A server may, for example, attempt to update a resource on POST but only search for it on GET.
Also, with GET, you can send data. In jQuery, it just gets serialized into the query string ($.get("someplace", data: { foo: "bar" }) gets sent as $.get("someplace?foo=bar")).
I am trying to send a very long POST request as an AJAX call in my application. Up until the query length exceeds ~7585 characters (incl. page name) the request goes through fine. However, there is a definite limit going on as adding a single character will make the request fail.
I have ensured that the tomcat server.xml config does not specify maxPostSize, and the documentation says it defaults to 2MB, which is way more room than I am using.
Am I missing something here? I am suspicious that this is a limitation being imposed by the web browser (Firefox 3.6.18).
If this is just an unfortunate truth, how do people get around this? By batching the data into smaller chunks manually? It seems like this would be a common problem for people. Thanks!
Several of my ajax applications in the past have used GET request but now I'm starting to use POST request instead. POST requests seem to be slightly more secure and definitely more url friendly/pretty. Thus, i'm wondering if there is any reason why I should use GET request at all.
I generally set up the question as thus: Does anything important change after the request? (Logging and the like notwithstanding). If it does, it should be a POST request, if it doesn't, it should be a GET request.
I'm glad that you call POST requests "slightly" more secure, because that's pretty much what they are; it's trivial to fake a POST request by a user to a page. Making it a POST request, however, prevents web accelerators or reloads from re-triggering the action accidentally.
As AJAX, there is one more consideration: if you are returning JSON with callback support, be very careful not to put any sensitive data that you don't want other websites to be able to see in there. Wikipedia had a vulnerability along these lines where the user anti-CSRF token was revealed via their JSON API.
All good points, however, in answer to the question, GET requests are more useful in certain scenarios over POST requests:
They can be bookmarked
They can be cached
They're faster
They have known consequences (assuming they don't change data), so visiting them multiple
times is not a problem.
For the sake of posterity, updating this comment with the blog notes re: point #3 here, all credit to Omar AL Zabir (the author of the referenced blog post):
"Atlas by default makes HTTP POST for all AJAX calls. Http POST is
more expensive than Http GET. It transmits more bytes over the wire,
thus taking precious network time and it also makes ASP.NET do extra
processing on the server end. So, you should use Http Get as much as
possible. However, Http Get does not allow you to pass objects as
parameters. You can pass numeric, string and date only. When you make
a Http Get call, Atlas builds an encoded url and makes a hit to that
url. So, you must not pass too much content which makes the url become
larger than 2048 chars. As far as I know, that’s what is the max
length of any url.
Another evil thing about http post is, it’s actually 2 calls. First
browser sends the http post headers and server replies with “HTTP 100
Continue”. When browser receives this, it sends the actual body."
You should use GET where you're doing a request which has no side effects, e.g. just fetching some info. This request can:
Be repeated without any problem - if the browser detects an error it can silently retry
Have its result cached by the browser
Be cached by a proxy
These things are all good. Anything which is only retrieving data (particularly public data) should really be a GET. The server should send sensible Last-Modified: and Expires: headers to allow caching if required.
There is one other difference not mentioned by anyone.
GET requests are passed in the URL string and are therefore subject to a length limit usually dependent on the browser. It seems that most are around 2000 chars.
POST requests can be much much larger - in fact not limited really. So if you're needing to request data from a web server and you're passing in lots of parameter information then a POST request might be the only option.
So, as mentioned before really a GET request is for requesting data (no side effects) while a POST request is generally used for transmitting data back to the server to be stored (with side effects). e.g. Use POST to upload a file. GET to retrieve a file.
There was a time when IE I believe had a very short GET URL string. Some applications like Lotus notes use large numbers of random characters to represent document id's. I had the displeasure of using another product that generated random strings so the page URL was unique each time. The random string was HUGE... and it didn't always work with IE6 from memory.
This might help you to decide where to use GET and where to use POST:
URIs, Addressability, and the use of HTTP GET and POST.
POST requests are just as insecure as GETs. The main difference is that POST is used to modify the state of the server application, while GET only requests data from it.
The difference matters when you use clean, "restful" URLs, where the URL itself specifies the resource, and the different methods trigger different actions on the server side.
Perhaps most importantly, GET is book-markable / viewable in url history, and searchable with Google.
POST is important where you don't want the event to be bookmarkable or able to be typed in as a URL - otherwise you (or Google crawling your URLS) could end up accidentally doing things like deleting users from your system, for example.
GET
POST
In GET method, values are visible in the URL
In POST method, values are not visible in the URL.
GET has a limitation on the length of the values, generally 255 characters.
POST has no limitation on the length of the values since they are submitted via the body of HTTP.
GET performs are better compared to POST because of the simple nature of appending the values in the URL.
It has lower performance as compared to GET method because of time spent in including POST values in the HTTP body
This method supports only string data types.
This method supports different data types, such as string, numeric, binary, etc.
GET results can be bookmarked.
POST results cannot be bookmarked.
GET request is often cacheable.
The POST request is hardly cacheable.
GET Parameters remain in web browser history.
Parameters are not saved in web browser history.
Source and more in depth analysis: https://www.guru99.com/difference-get-post-http.html