Intermittent JQuery Crashes - help needed
I am working on a problem in WLUK which has been raised by a customer and it's frustrating them. The problem is intermittent so it's hard to reproduce and hence it'll be hard to test any fix. We use JQuery (1.4.2) to submit a form using $form.submit(function() {}) the function builds a string which is appended to the form in a hidden field. This string is getting large, too large I believe and causing the problem. The problem is that the request never gets sent we get "Internet Explorer cannot display the webpage" on screen. I will be grateful if anyone can shed some light on this.
Tagged:
1
Best Answer
-
#Browser Limitations# [IE 4.0-9.0](
http://support.microsoft.com/kb/q208427) (and possibly 10.0, haven't found any data on it yet) all have a maximum URL length of 2083 characters in the address bar, including a "sub-maximum" of 2048 characters in the path portion of the URL (so everything after the TLD or port). Most other browsers either [do not have URL length limitations or have extremely _high_ limits, e.g. 65535 characters](
http://stackoverflow.com/questions/417142/what-is-the-maximum-length-of-a-url). Interestingly, though, this seems to be a hard limit when putting the URL into the address bar _but_ testing has shown that URLs can actually be substantially longer when used as an `href` in a hyperlink (`a` tag). ###Why can that affect form submission?### If your form has a `method` of [HTTP] GET, then its data is all being appended to the `action` URL as query parameter pairs and is thus subject to the maximum URL length restrictions in IE. If your form has a `method` of [HTTP] POST, however, then its `action` URL is not modified (though still subject to the maximum URL length restrictions) as its data is instead sent as pairs in the body of the request which is _NOT_ submit to any length restrictions from the browser's perspective. A POSTed form submission will also have additional HTTP headers added to its request to describe the body (e.g. `Content-Type`, `Content-Length`, etc.). #Server Limitations# Additionally, the web server applications (e.g. Apache, IIS, etc.) that are fulfilling the URL requests will likely have a maximum URL limit of its own. Most are higher than the browser's (well, IE's) limit, and most are configurable. However, if the URL requested exceeds the server's limitations, then the server is required to reply with [HTTP error code 414 ("Request-URI Too Long")](
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.15). Similarly, web server applications sometimes have limits for the amount of data they will accept in an HTTP `POST`/`PUT` request body. Again, this is usually configurable. #Other Possibilities# IE7 in particular also has some reported issues with client-server interactions for POSTs in which it chokes. Other examples I found in the wild (#1 is caused by client-side issues, #2-4 are all caused by server issues): 1. [Possible issues with jQuery form submission in IE if triggered via `click` rather than `submit`](
http://stackoverflow.com/questions/6487748/internet-explorer-cannot-display-the-webpage-after-using-jquery) 2. [IE7 sends an extra CrLf at the end of the request body, making it longer than the reported content length, server rejects it as a mismatch](
https://groups.google.com/forum/?fromgroups=#!topic/pylons-discuss/vGmCgpb9JuU) 3. [DNS returns an IP Address List with more than 5 IPs and the first 5 all fail](
http://support.microsoft.com/kb/2293762) 4. [Form submission with a file upload resulting in an HTTP redirect to non-absolute URL bombs](
http://stackoverflow.com/questions/6948128/ie-doesnt-follow-redirect-gives-internet-explorer-cannot-display-the-webpage)2
Answers
-
Which versions of IE are affected by this?0
-
Also, is your form submitted via HTTP GET or POST?0
-
thanks James. I made some progress and I believe my problem is related to a proxy server somewhere in the system. IE is not blameless since the problem is most prevalent in IE and it's IE that the customer uses. The large URLs (or requests) are not good and they are the issue here, hitting a limit in a proxy server I believe. I changed the form to be submitted using POST rather than GET and my test scenarios are now working.0
-
I have figured this out, please see my comment in response to James's post. Thanks for looking0
Categories
- All Categories
- 6 AHS
- 39 Alpha
- 161 App Studio
- 4 Block Chain
- 4 Bot Platform
- 16 Connected Risk APIs
- 47 Data Fusion
- 30 Data Model Discovery
- 608 Datastream
- 1.3K DSS
- 577 Eikon COM
- 4.9K Eikon Data APIs
- 7 Electronic Trading
- Generic FIX
- 7 Local Bank Node API
- Trading API
- 2.7K Elektron
- 1.3K EMA
- 236 ETA
- 519 WebSocket API
- 33 FX Venues
- 10 FX Market Data
- 1 FX Post Trade
- 1 FX Trading - Matching
- 12 FX Trading – RFQ Maker
- 5 Intelligent Tagging
- 2 Legal One
- 20 Messenger Bot
- 2 Messenger Side by Side
- 9 ONESOURCE
- 7 Indirect Tax
- 59 Open Calais
- 264 Open PermID
- 39 Entity Search
- 2 Org ID
- PAM
- PAM - Logging
- 8.4K Private Comments
- 6 Product Insight
- Project Tracking
- ProView
- ProView Internal
- 20 RDMS
- 1.4K Refinitiv Data Platform
- 367 Refinitiv Data Platform Libraries
- 3 Refinitiv Due Diligence
- LSEG Due Diligence Portal API
- 3 Refinitiv Due Dilligence Centre
- Rose's Space
- 1.1K Screening
- 18 Qual-ID API
- 13 Screening Deployed
- 23 Screening Online
- 10 World-Check Customer Risk Screener
- 990 World-Check One
- 44 World-Check One Zero Footprint
- 45 Side by Side Integration API
- Test Space
- 3 Thomson One Smart
- 1.2K TR Internal
- Global Hackathon 2015
- 2 Specialists Who Code
- 10 TR Knowledge Graph
- 150 Transactions
- 142 REDI API
- 1.7K TREP APIs
- 4 CAT
- 21 DACS Station
- 117 Open DACS
- 1.1K RFA
- 103 UPA
- 172 TREP Infrastructure
- 224 TRKD
- 886 TRTH
- 5 Velocity Analytics
- 5 Wealth Management Web Services
- 60 Workspace SDK
- 9 Element Framework
- 5 Grid
- 13 World-Check Data File
- Yield Book Analytics
- 46 中文论坛