I'm using HTTP requests in my program to pass data via a querystring to a web-based status page. The requests are of the form:
http://www.example.com/poststatus.asp?ID="FRED"&widgetscompleted=1234&...parameterN=valueN
The ASP page parses the querystring and updates a database.
My question is: what is the sensible length limit of the querystring? I've seen mention of 2000-odd bytes but that seems to be browser-related and there is no browser involved here - just my app (using Indy) and IIS.
Browser dependent, for more this might help
With the limitation on characters, what i usually do is minimize the querystring values from your example: &widgetscompleted= could be abreviated to &wc=.
I am certain if you minimize these, the length shouldn't be an issue.
Related
I've got the following problem:
We've updated our components. Before the update a page request size was 22kb in size (140k characters, including whitespace). After the update the request size is 180~kb (180k characters, including whitespace).
I would have assumed there's a direct relation of request answer length and the characters sent so i can't quite explain how a 30%~ increase in characters results in 9 times the request content sent.
Does this ring a bell to anyone? I can't quite see where the difference is comming from.
The reason for this was, that the old version has gzip compression enabled while the new one does not, despite the configuration beeing set to have it enabled. so it's just a matter of research as to why it is not returning gzip encoded content now.
can anyone help me with the length of maximum characters that can be contain in a normal HTML text box....
As to the HTML side, when the maxlength attribute is not specified, then the maximum length of the input value is unlimited. However, if you're sending the request as GET instead of POST, then the limit will depend on the webbrowser and webserver used. The HTTP 1.1 specification even warns about this, here's an extract of chapter 3.2.1:
Note: Servers ought to be cautious about depending on URI lengths
above 255 bytes, because some older client or proxy
implementations might not properly support these lengths.
As to the webbrowsers, the practical limit is in Firefox about 8KB, in Opera about 4KB and in IE and Safari about 2KB. So the total length of all inputs should not exceed this if you want a succesful processing. As to the webservers, most have a configureable limit of 8KB. When the limit is exceeded, then it will often just be truncated, but some webservers may send a HTTP 414 error.
When you're sending the request as POST, then the limit depends on the server config. Often it's around 2GB. When it's exceeded, the server will often return a HTTP 500 error.
Default maxlength is unlimited for a <input type='text'/>. You may optionally provide this value to constrain input (but there's no guarantees the browser will enforce the rule).
A <textarea> does not support a maxlength so unlimited characters are accepted for input.
(ref: https://www.w3.org/MarkUp/HTMLPlus/htmlplus_41.html)
RE: Long string breaking during submit
There can be a maximum size to the amount of data submitted from a form when using the method get (the default if not specified). It's only a can because many browsers allow many more characters now. If you use a form with the post method, there is no maximum to the amount of data submitted.
In HTML4, the maxlength attribute is only supported on the input element. HTML5 extends this to allow it on textarea as well. A quick test works in Firefox 4 and WebKit, but not Firefox 3 or Opera. If you need support for HTML4, use JavaScript to manually limit the length.
I've a web application (well, in fact is just a servlet) which receives data from 3 different sources:
Source A is a HTML document written in UTF-8, and sends the data via <form method="get">.
Source B is written in ISO-8859-1, and sends the data via <form method="get">, too.
Source C is written in ISO-8859-1, and sends the data via <a href="http://my-servlet-url?param=value¶m2=value2&etc">.
The servlet receives the request params and URL-decodes them using UTF-8. As you can expect, A works without problems, while B and C fail (you can't URL-decode in UTF-8 something that's encoded in ISO-8859-1...).
I can make slight modifications to B and C, but I am not allowed to change them from ISO-8859-1 to UTF-8, which would solve all the problems.
In B, I've been able to solve the problem by adding accept-charset="UTF-8" to the <form>. So it sends the data in UTF-8 even with the page being ISO.
What can I do to fix C?
Alternatively, is there any way to determine the charset on the servlet, so I can call URL-decode with the right encoding in each case?
Edit: I've just found this, which seems to solve my problem. I still have to make some tests in order to determine if it impacts the perfomance, but I think I'll stick with that solution.
The browser will by default send the data in the same encoding as the requested page was returned in. This is controllable by the HTTP Content-Type header which you can also set using the HTML <meta> tag.
The accept-charset attribute of the HTML <form> element should be avoided since it's broken in MSIE. Almost all non-UTF-8 encodings are ignored and will be sent in platform default encoding (which is usually CP-1252 in case of Windows).
To fix A and B (POST) you basically need to set HttpServletRequest#setCharacterEncoding() before gathering request parameters. Keep in mind that this is an one-time task. You cannot get a parameter and then change the encoding and then "re-get" the parameters.
To fix C (GET) you basically need to set the request URI encoding in the server configuration. Since it's unclear which server you're using, here's a Tomcat-targeted example: in the HTTP connector set the following attribute:
<Connector (...) URIEncoding="ISO-8859-1" />
However, this is already the default encoding in most servers. So you maybe don't need to do anything for C.
As an alternative, you can grab the raw and un-URL-encoded data from the request body (in case of POST) by HttpServletRequest#getInputStream() or from the query string (in case of GET) by HttpServletRequest#getQueryString() and then guess the encoding yourself based on the characters available in the parameters and then URL-encode accordingly using the guessed encoding. A hidden input element with a specific character which is different in both UTF-8 and ISO-8859-1 may help a lot in this.
I'm answering myself in order to mark the question as solved:
I found this question, which covers exactly the same problem I was facing. The javax.servlet.Filter was the solution for me.
Has anyone used Google translation API ? What is the max length limit for using it?
The limit was 500... now it is 5000 chars.
source
500 characters
source
At the moment, the throttle limit is 100,000 characters per day. Looks like you can apply to have that limit increased/removed.
I've used it to translate Japanese to English.
I don't believe the 500 char limit is true if you use http://code.google.com/p/jquery-translate/, but one thing that is true is you're restricted as to the number of requests you can make within a certain period of time. They also try to detect whether or not you're sending a lot of requests with a similar period, almost like a mini "denial of service" attack.
So when I did this I wrote a client with a random length sleep between requests. I also ran it on a grid so all the requests didn't come from a single IP address.
I had to translate ~2000 Java messages from a resource bundle from Japanese to English. It worked out pretty nicely, as long as the text was single words. Longer phrases with context came out awkwardly.
Please have look at this link it will give the correct answer at the bottom of the page.
https://developers.google.com/translate/v2/faq
What is the maximum number of characters per request?
The maximum size of each text to be translated is 5000 characters, not including any HTML tags.
You can send source strings of up to 5,000 characters, but there are a
few provisos that are sometimes lost.
You can only send the 5,000 characters via the POST method.
If you use GET method, you are limited to 2,000-character length limit on urls. If a url is longer than that, Google's servers will just reject it.
Note: 2,000-character limit including the path and the rest
of the query string as well + you must count uri encoding (for instance every space becomes a %20, every quotation
mark a %22)
The Cloud Translation API is optimized for translating of smaller requests. The recommended maximum length for each request is 5K characters (code points). However, the more characters that you include, the higher the response latency. For Cloud Translation - Advanced, the maximum number of code points for a single request is 30K. Cloud Translation - Basic has a maximum request size of 100K bytes.
https://cloud.google.com/translate/quotas
I have an ASP.Net 3.5 platform and windows 2003 server with all the updates.
There is a limit with .Net that it cannot handle more than 260 characters. Moreover if you look it up on web, you will find that IE 6 fails to work if it is not patched at above 100 charcters.
I want to have the rewrite path module to be supported on maximum number of browsers, so I am looking for an acceptable limit to which I can create verbose URL's.
A Url is path + querystring, and the linked article only talks about limiting the path. Therefore, if you're using asp.net, don't exceed a path of 260 characters. Less than 260 will always work, and asp.net has no troubles with long querystrings.
http://somewhere.com/directory/filename.aspx?id=1234
^^^^^^^- querystring
^^^^^^^^^^^^^^^^^^^^^^^^ -------- path
Typically the issue is with the browser. Long ago I did tests and recall that many browsers support 4k url's, except for IE which limits it to 2083, so for all practical purposes, limit it to 2083. I don't know if IE7 and 8 have the limitation, but if you're going to broad compatibility, you need to go for the lowest common denominator.
There is no length limit specified by the W3C, but look here for practical limits
http://www.boutell.com/newfaq/misc/urllength.html
pick your own limit from that.
The default limit in IIS is 16,384 characters
But IE doesn't support more than 2083
More info at link
This article gives the limits imposed by various browsers. It seems that IE limits the URL to 2083 chars, so you should probably stay under that if any of your users are on IE.
Define "optimum" for your application.
The HTTP standard has a limit (it depends on your application):
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 ought to be cautious about depending on URI
lengths above 255 bytes, because some older client or proxy
implementations might not properly support these lengths.
So the question is - what is the limit of your program, or what is the maximum resource identifier size your program needs to perform all its functionality?
Your program should have a natural limit.
If it doesn't you might as well stick it as 16k, as you don't have enough information to define the problem.
-Adam
Short ;-)
The problem is that every web server and every browser has own ideas how long the maximum is. The RFC for the HTTP protocol gives no maximum length. IE limits the get to 2083 characters, the path itself may be at most 2,048 characters. However, this limit is not universal. Firefox claims to support at least up to 65,536, however some people verified that on some platforms even 100,000 characters work. Safari is above 80,000 (tested). Apache server on the other hand has a limit of 4,000. Microsofts Internet Information Server has one being 16,384 (but it is configurable).
My recommendation is to stay below 2'000 characters in any case. This is not guaranteed to work with every browser in the world (especially not older ones), but it will work with all modern browsers. Further I recommend to use POST wherever possible (e.g. avoid using GET for FORM submits - if some users want to simulate a FORM submit via GET, make sure your application supports the desired parameters either via POST or via GET, but when you submit the page yourself via a button or JS, prefer POST over GET).
I think the RFC says 4096 chars but IE truncates down to 2083 characters. Stay well under that to be safe.
Practically, shorter URLs are friendlier.
More information is needed but for normal situations I would say try to keep it under 150 for sure. If for nothing else than pure ascetics, I hate when someone sends me a GI-NORMOUS link...
Are you passing values through the query string? I assume that is why you asked, correct?
What is "optimum" anyway?
GET requests can be several kB in length, so this is entirely subjective.
I'd say - stay within the address bar length of a maximized 1024x768 window to be user friendly.
If you're trying to get people to remember the URL, I wouldn't go more than 60. Use words if possible, because it's easier to remember "www.example.com/this-is-the-url" than "www.example.com/179264". If you're trying to get the page indexed, you could probably go more. The spiders look for words in the title too, and some people may be more likely to click on the link if the URL looks readable.
When you say "Optimum", I think "Easily Accessible To Users", in which case, I think the shorter the URL, the better. I would think 20-30 characters maximum, in that case.