I am doing an HTTP GET with JSONP from GWT..
The URL contains +1000 character.
The problem is the request doesn't reach the server
Do you see the problem here in the length of the HTTP URL? as when I do request the same server with fewer characers (+500 character) I get it working..
BTW, it appears to be IE8-only issue.
Thanks?
There is a maximum lenght for IE, but 1000 chars should be fine. As documented here: http://support.microsoft.com/kb/q208427/ IE should handle upto 2,083 characters.
In any case: it is recommended to do posts for such large datasets. POST does not have these limits.
Related
When I called Microsoft Translator Text API's TranslateArray, Error 413 (Request Entity is too Large) occurred.
I recognize API limitations:
The total of all texts to be translated must not exceed 10000 characters.
The maximum number of array elements is 2000.
When the request's Content-Length header is greater than 30721, the request fails with a 413 error even though the above api limitations are observed.
is there any other limitation?
If anyone is still running into this issue, upgrading to the latest google-cloud-translate client should fix the issue. For more information, the PR here fixed the problem for me, which was that the client was using GET requests instead of POST requests.
Note: This should also fix a related error of getting 411 (Length Required) when cutting off a piece of text to only translate the first N characters.
Why if I submit an URL like:
localhost:38245/TeamWork/Group/1/LONG-COMMENT-POSTED-BY-USER ,
I get an error that says "Bad Request - invalid URL HTTP Error 400. The request URL is invalid." ?
The default maximum length of a URL is 4096 in IIS. You may well be breaching that with the comment posted by the user. Generally, the best way to transfer that kind of data is by POST rather than in a URL. You can either trim the comment to a more suitable size of increase the maxUrl value in the requestLimits section of your IIS config: http://msdn.microsoft.com/en-us/library/ms689462%28v=vs.90%29.aspx
Firstly, HTTP 400 error is intended for cases when the client has made an error. As you've noticed yourself it's a bad request error. So that means possibly due to bad syntax the request can not be carried out. As Mike Brind mentions, you're most probably exceeding the maximum length of the URL (the default value anyway)
Secondly, why are you trying to "submit" a long post by URL? Use the POST method instead. A way to do this is by using Jquery's Post method to do this. See this. Or simply by calling the form's submit method through OnClick method or however the user is submitting the form.
POST is perfect for transmitting large amounts of data. So submitting data from the client side, the easiest way by far is to use POST to archieve this.
As you have yourself stated in the Question code part,
localhost:38245/TeamWork/Group/1/LONG-COMMENT-POSTED-BY-USER
the Long comment by user, must be inside the limits that are in the web.config file of your website.
Secondly, no Server would allow a very Long Url thinking that the user might be trying to post a malware. Also, using short URLs is good for Data transfer as they consume less data.
From the limits on Requests one would easily come to understand that the URL must be less than 4096bytes, only 4KB. So do you think, all that URL would be 4KB?
As Mike has suggested to use POST request to send the long data, I would also suggest you to use HttpPost requests to send this type of long data. This way, Browser would encrypt the data and sending it as an attachment to the request.
I know differences and advantages of each command, my question is could I replace POST requests with GET everywhere? And which these commands calls by default while sending request from html form?
could I replace POST requests with GET everywhere
No (and it would be a terrible idea to try).
Things that a form can do with POST that you can't do with GET include:
Sending lots of data
Sending files
There are other things that would simply be stupid to do with GET.
From http://www.w3.org/TR/html5/forms.html#attr-fs-method :
The method and formmethod content attributes are enumerated attributes
with the following keywords and states:
The keyword get, mapping to the state GET, indicating the HTTP GET
method. The keyword post, mapping to the state POST, indicating the
HTTP POST method. The invalid value default for these attributes is
the GET state. (There is no missing value default.)
When using GET to transfer data from the client to the server, the data is added to the URL, there is not BODY of the request. There is usually a limit on how long a URL can be, in the old days this was 1024 characters but that really depends on the server software and server middleware and even the browser.
This means if you want to transfer loads or data or upload a file to the server, you can not do it with GET.
I am aware that JSON strings often have a max length defined in either Apache on PHP, however where is the max length for JSON strings defined in Grails using TomCat?
The JSON string I am sending is 13,636 characters in length, however I can shorten it a lot (although I don't want to while we're testing) - also, we may be sending images via JSON in the future which I've read requires base64 encoding and thus a considerable overhead. If we were to do such a thing then I am worried that if this limit is causing problems, it's something we should overcome now.
If there is no limit, then perhaps I am doing something wrong. I have a finite amount of domain objects that I am encoding as JSON using domainInstance as grails.converters.deep.JSON - this is done using a for loop and each time the JSON string is appended to a StringBuilder
I then render the StringBuilder in a view using render(stringBuilder.toString()) and the first JSON string is fine, however the second is truncated near to the end. If I were to guestimate I'd say I am getting around 80% of the total length of the StringBuilder.
EDIT/SOLUTION: Apologies guys & girls, I've noticed that when I view source on the page I get the complete JSON string, however when I just view the page it's truncated. It's an odd error, I'll accept answers on why it's truncated, though. Thanks.
There is a maximum size in Tomcat for POST requests, which you may be concerned with later if you start sending huge JSON / Base64 image requests (like you mentioned).
The default value in tomcat is 2,097,152 bytes (2 MB); it can be changed by setting the maxPostSize attribute of the <Connector> in server.xml.
From the docs (for maxPostSize in Tomcat 7):
The maximum size in bytes of the POST which will be handled by the
container FORM URL parameter parsing. The limit can be disabled by
setting this attribute to a value less than or equal to 0. If not
specified, this attribute is set to 2097152 (2 megabytes).
This is pretty straightforward to configure if you're deploying a Grails war to a standalone Tomcat instance. However, I can't find much about actually configuring server.xml if you're using the tomcat plugin. If it were me, I'd probably just run large-file tests using the war instead of with grails run-app.
I have a problem with IE(7&8) browser's handling of security certificate errors.
Our application needs to send out a secure link to the user's email, consisting of a randomly generated token which may have special characters. So before sending out, we encode the token. The sample URL would be like this:
localhost:8080/myapp?t=7f%26DX%243q9a
When the user opens this in IE, it gives the certificate error page. ("There is a problem with this website's security certificate.") The continue link ON that page re-encodes our token into something else:
localhost:8080/myapp?t=7f%2526DX%25243q9a
(Thus the user would be sent to a slightly different URL than what we're expecting, as you can see.)
Here, you can see that the "%" s I'd sent get turned into "%25" s. how can I decode the token correctly after this?
Nasty!
If this is a reproducible bug and not funny behaviour caused by some character set issues or something - it doesn't look like it! - then I think your only way to work around it is to use an encoding method for the parameter that uses only letters and numbers, like base64.