Bug 19758

Summary: XMLHttpRequest timeout in 60 second
Product: WebKit Reporter: Sunhwan Jo <sunhwanj>
Component: XMLAssignee: Nobody <webkit-unassigned>
Status: RESOLVED FIXED    
Severity: Normal CC: alexcheng1982, ap, fabian, mark, sam
Priority: P2 Keywords: InRadar
Version: 528+ (Nightly build)   
Hardware: Mac   
OS: OS X 10.5   
URL: http://devel.charmm-gui.org/test2.html

Sunhwan Jo
Reported 2008-06-24 16:50:23 PDT
ajax request time out in 60 second. the attached url calls a php script that sleeps 60 seconds. It works fine (display alert window and say 'done') in firefox, and will not work in Safari (blank alert window). Below is the slightly modified script. test.php?duration=59 will be fine test.php?duration=60 will be failed. test.php ------ <script src="javascripts/prototype.js" type="text/javascript"></script> <script> var myAjax = new Ajax.Request( 'http://devel.charmm-gui.org/sleep.php', { method: 'get', parameters: 'duration=<?=$_GET['duration']?>', onComplete: showResponse }); function showResponse(oReq) { alert(oReq.responseText); } </script> ---- sleep.php ---- <? sleep($_GET['duration']); echo 'done'; ----
Attachments
Alexey Proskuryakov
Comment 1 2008-06-25 02:39:56 PDT
This is currently by design. Does this cause problems for you?
Sunhwan Jo
Comment 2 2008-06-25 08:00:20 PDT
Hmm, I thought there shouldn't be a timeout in ajax request. I have a form that takes very long time (40 minutes). It worked fined before, and suddenly stopped working after Mac OS X 10.5.3 update. So, I went to webkit developers and they suggested me to do this in asynchronous way. But it also fails. Thanks, Sunhwan (In reply to comment #1) > This is currently by design. Does this cause problems for you? >
Alexey Proskuryakov
Comment 3 2008-06-25 08:25:52 PDT
The timeout was certainly there for sync requests, although I never tested async ones before. But please note that 40 minutes is a long time, I would expect that if you are behind a proxy, it will close the connection much earlier (unless there is some heartbeat data transferred just to keep the connection alive).
Sunhwan Jo
Comment 4 2008-06-25 08:34:23 PDT
I understand. But, just had been frustrated by changed behavior of Safari. So, do you think this is not a bug, right? I'm still curious because, there was a numerous attempts to introduce timeout for xmlhttprequest using javascript because there was no timeout in browser. The website facilitate scientific calculation, so there is no way to shorten the processing time, and make it interactive.
Mark Robertshaw
Comment 5 2008-08-20 02:17:48 PDT
Hi There We have just encountered the exact same problem with the new 60 second timeout, introduced by an upgrade to Mac OS. This has caused a show stopping bug in a critical application using the Adobe AIR framework as an RIA. As an RIA is not a conventional web application, we feel that the arguments about long running processes are not valid, and in fact our customer relies upon long running tasks for everyday operation. At the very least, we would expect to be able to configure the timeout on XMLHttpRequest at our whim for particular (especially synchronous) requests where we expect long running events. We understand that you consider 40 minutes as too long, so do we ! However 5 - 10 minutes is not an uncommon wait time for complex database processing and analysis. By the way, we tried it asynchronously and the same "feature" is still evident. Can we have a fix or a workaround please to avoid serious refactoring / rewriting of our code. Thanks a lot Mark Robertshaw
Alexey Proskuryakov
Comment 6 2008-08-20 02:43:31 PDT
Mark Robertshaw
Comment 7 2008-08-20 02:53:39 PDT
Please elaborate on this..... We're not sure what <rdar://problem/6161817> means....
Alexey Proskuryakov
Comment 8 2008-08-20 03:43:58 PDT
This is a number that will be used by Apple for tracking this bug internally, it does not really mean much for anyone else. You can request some basic status from Apple by e-mailing <devbugs@apple.com> and quoting this number.
Fabian Mailinator
Comment 9 2008-08-20 13:22:11 PDT
> This is currently by design. Does this cause problems for you? > Yes, it does. As a user I have at least one site I visit which performs a site search and, eventually, spits all the results out asynchronously. The search is slow and can take up to 5 minutes. It no longer works. What problem are these timeouts designed to address? A slow site/script can always be handled by the user with the <stop> button. It is generally wrong to make assumptions about how your tool will be used. Timeouts during firmware upgrades to devices are going to be a SERIOUS issue because it could brick the device, as just one other example.
Fabian Mailinator
Comment 10 2008-08-20 14:29:39 PDT
Also, it's now impossible to upload photos to many sites. LinkedIn, as one example, if you try to upload a large profile picture the processing on their end to create the thumbnail takes more than 60 seconds. So safari drops the connection and the upload fails. Lose lose lose. Timeouts are like vice-grips: the wrong tool for every problem.
Alexey Proskuryakov
Comment 11 2008-09-09 05:55:31 PDT
This was fixed in r36108 - please verify the fix with a nightly build, available from <http://nightly.webkit.org>.
Alexey Proskuryakov
Comment 12 2008-10-16 02:16:13 PDT
*** Bug 21585 has been marked as a duplicate of this bug. ***
Alexey Proskuryakov
Comment 13 2011-02-18 10:30:02 PST
*** Bug 20463 has been marked as a duplicate of this bug. ***
Note You need to log in before you can comment on or make changes to this bug.