Unfortunately, I have not been able to narrow down this problem specifically. I am using the latest version of safari and the latest build of tiger. When I upload files to certain php scripts, safari hangs while other browsers upload the file and behave as expected. There are no crashes, etc, it just hangs. I will attach a process trace on safari during one of these hangs to this bug report. This may be related to how safari handles the connection, or how php retrieves the file; I'm not sure exactly. Darien suggested that I open a ticket anyways. If I am able to find more specific details, I will get them to this ticket.
Created attachment 4699 [details] Process trace on safari during hang
The sample here just shows Safari quietly doing nothing. Any copy of Safari that was not doing anything at the time would show a sample something like this. So there's no clue.
Kevin, by "hang", do you mean nothing appears to be happening? Is there an actual lock-up, i.e. are you prevented from doing anything else in Safari during the upload? Does the cursor change to a spinning beachball?
Reassigning to webkit-unassigned, to make sure more people see this.
Just adding my own 2 cents, we're what appears to be the same behavior. Using Firefox and IE, uploads work like a charm. Using Safari, they hang intermittently. We've done some network traces and it looks as though the connection is being dropped, or severed. It is definitely some setting in our network, and this did not used to happen, so we are hunting and hunting to discover what the setting is. In the meantime, it appears as though there is some obscure condition that chokes up Safari, but not the other browsers. If/when we figure out what is up, I'll post more information. Just wanted to chime in and say "me, too!"
I should also mention that we are not using PHP (we're Ruby on Rails), but we have verified that the problem occurs independently of the framework and language used. I've written a simple (bash) shell script CGI which I can post files to, and Safari has been observed to hang when uploading to this script.
(In reply to comment #6) > I've written a simple (bash) shell script CGI which I can post > files to, and Safari has been observed to hang when uploading to this script. Please post the script to this bug so that others may download and test with it. Thanks!
Created attachment 6478 [details] bash CGI script for testing file uploads This is a script you can use to test the file uploads. On a good day, the stall rate is about 1 upload in 10. On a bad day, it might be as high as one in 3, or even 2. I should mention also that stalls have been observed when using Apache 1.3.33 as the server, as well as when using lighttpd 1.4.6, 1.4.9, and 1.4.10. Note that the script does not actually store the file (or even read the file from the network). It simply acknowledges that the request was recieved. When a stall occurs, only the request body is received--the body of the request is never received, and Safari acts as though it is waiting for some acknowledgement before sending the body. Anyway, best of luck to those who come after. I'll be spending many a late night on this, I'm sure.
"only the request body is received--the body of the request is never received" Apologies, that should read "only the request _headers_ are received--the body of the request is never received.
It appears to be an issue with keep-alive requests. Having the web server disable keep-alive requests for Safari (using SetEnvIf in apache or a conditional on "useragent" in lighttpd), the problem goes away. Still not sure why this happens in some settings and not in others, but it has definitely cleared up the problem for us.
Not sure if this adds anything useful to the discussion, but I'm seeing this problem in my Rails app running on lighttpd. I'm just using a plain multipart form with a file upload, and every so often, Safari's request just seems to go missing enroute to the server. I'm not seeing anything in the server logs to indicate that the request was received, and Safari just sits there waiting for a reply, and eventually times out.
Just an addendum to confirm that Jamis' suggestion on disabling keepalives seems to have cleared up the problem. For anyone having the same issue, you probably want something like this in lighttpd.conf : $HTTP["useragent"] =~ "^(.*MSIE.*)|(.*AppleWebKit.*)$" { server.max-keep-alive-requests = 0 }
Jamis and Jonathan: Could you document (in this bug) the client and server operating systems and versions, as well as the names and versions of the (distro-specific-packaged) web server software and the version of Safari, on which you experienced this bug? FOR EXAMPLE: CLIENT: Mac OS X 10.4.4 (PPC) with Safari 2.0.3 (417.8) SERVER: Debian GNU/Linux 3.1 (kernel-image-2.4.27-2-386_2.4.27-10sarge1_i386) with apache_2.0.54-5. I have a feeling this problem may not be related directly to WebKit, but instead a lower-level issue (like Foundation classes) or perhaps even a bad interaction between the Mac OS X TCP/IP stack and the Linux or other O/S TCP/IP stack. It would be very helpful to document these issues so that they will be easier to reproduce. Thanks! Also marking this bug as confirmed since two different people have seen this bug.
CLIENT: Mac OS X 10.3.x, 10.4.x (PPC, various) with Safari 1.3, 2.0.x (various) SERVER: FreeBSD 5.4-RELEASE-p6 #7 with Apache/1.3.33, lighttpd 1.4.6, lighttpd 1.4.9, lighttpd 1.4.10 Also possibly observed running stock Apache on Mac OS X 10.4.4, Darwin Kernel Version 8.5.0
I should also note that it can't really be an issue too far down in the stack, because Firefox never observed the same behavior, whereas Safari on the same machine would.
I've seen this problem when the client and server are the same machine: CLIENT: Mac OS X 10.4.4 (PPC) with Safari 2.0.3 (417.8) SERVER: Mac OS X 10.4.4 (PPC) with lighttpd-1.4.8 Let me know if there's any more necessary information...I'm not overly familiar with how the server-end of things works, so wasn't sure if there was anything else that's relevant.
I can reconfirm this behaviour on the following set-up Client: Mac OS X 10.4.5, Safari 417.8 Server: Mac OS X Server 10.4.5, Apache 2.0.55 Am currently testing setting the following settings in the Apache config: # First load setenvif_module (usually already loaded) LoadModule setenvif_module modules/mod_setenvif.so # Match Safari and set special setenvif keyword "nokeepalive" BrowserMatch Safari nokeepalive The BrowserMatch directive can be set inside a virtual host or particular directory if you only need it there. This is a major bug for us (we build web applications for e-learning - lots of file uploads), we might have had to remove Safari from our supported browsers, even though we all use it internally. I think this bug should really have higher priority. Not everyone has the luxury of being able to adapt their server to cope with a Safari quirk. Here is an example of the user-level befuddlement that is being caused... http://forums.macrumors.com/showthread.php?t=166418 ... sorry if that's all a bit ranty, but this is a big deal for anyone authoring user interactive web-applications.
I too just spent about 5 hous trying to get to the bottom of this. Using rails & lighttpd and trying to upload an image file. Safari sends a partial request to the server (I can see it send the packet in tcpdump) but the server isn't seeing the whole request and everything seems to time out. Safari thinks the server is stalled and the server never formally accepts the request. The latest webkit 4/2/06 has this issue.
(In reply to comment #18) >I can see it send the packet in tcpdump Could you please attach the tcpdump output to this bug (from both server and client, if possible)? And if you have a world-accessible server that suffers from this problem, that would be extremely helpful.
Created attachment 7496 [details] Tcpflow capture of both a good and a failed request It looks like the difference between a successful and unsuccessful upload is that Safari sends two duplicated multipart requests, the server sees the first, waits for the data, gets a second request that is obviously treated as a post (albeit a screwed up incomplete post) that has a correct boundary delimiter, followed by the first real attachment. (great, Safari cant upload this to Bugzilla...)
I can reproduce this behavior on 10.4.6 (Intel) using a local lighttpd 1.4.11 (from DarwinPorts) and Rails 1.1.2.
*However*, in one variation (which always fails, even with keepalives off), if I remove an onsubmit from the form, it begins to work (reliably with keepalives off). With the onsubmit (which displays some content before the form gets submitted), the form is submitted properly, but without the data from the file field.
(In reply to comment #22) This sounds more like a WebKit bug (in contrast to the keepalive stalling issue, which sounds like an OS bug that needs to be reported via <http://bugreport.apple.com>). Could you please provide detailed steps to reproduce this (including lighttpd/Rails configs and the scripts used for testing)? Might be better to open a new bug for onsubmit.
WebKit bug reported as 8584 with a *very* basic PHP script that demonstrates the flaw.
Bug 8584 turned out to be unrelated. I cannot reproduce the problem with a locally installed Apache and the attached cgi script. I have installed lighttpd from DarwinPorts now - could someone please provide the further necessary steps? Does Rails need to be installed? How does one create "a plain multipart form with a file upload" there? How is the server even started? Sorry for such newbie questions, but I'll really need a very detailed instuction to reproduce this issue (and, judging from the lack of progress on this bug, other WebKit developers may be not professionals in Web development, as well, which I find understandable). Just thought that this issue is quite important...
Still no steps to reproduce and no reason to believe that this is a WebKit bug; closing as invalid.
For what it is worth, this is still an issue here. I've just not had anything more to add than what has already been said. However, I recently read this email: http://lists.apple.com/archives/macnetworkprog/2006/Dec/msg00021.html which appears to be describing the issue, and it includes detailed instructions at the network level for how to duplicate the problem. I figured that since it was relevant, I'd add it to this ticket and hope for the best.
Per this mailing list post, this bug has been filed as <rdar://problem/4876179>: http://lists.apple.com/archives/Web-dev/2006/Dec/msg00010.html The barrier to getting this issue resolved is lack of consistent reproduction. The people who see it are able to reproduce it all the time. The people who don't see it can't reproduce it at all. Per the mailing list post in Comment #27, we need a server that provides a keep-alive timeout where we can load a page, pick a file to upload, then upload the file. I chose http://validator.w3.org/ which advertises a keep-alive timeout of 15 seconds per its HTTP response headers. Steps to reproduce: 1. Open Safari. 2. Click on link: http://validator.w3.org/#validate-by-upload 3. Begin counting seconds (one-mississippi, two-mississippi, etc.) out loud as soon as I click the button. 4. Select an HTML file to upload. 5. When my count reaches 15, click "Check" button. When I follow the above instructions, I am never able to reproduce this bug. What am I doing wrong? Is my count not accurate enough? Am I waiting too long? Am I not waiting long enough? Does this only reproduce on servers on a local network instead of over the Internet? Please help me to reproduce the issue.
(In reply to comment #28) > When I follow the above instructions, I am never able to reproduce this bug. > What am I doing wrong? Is my count not accurate enough? Am I waiting too > long? Am I not waiting long enough? Does this only reproduce on servers on a > local network instead of over the Internet? > > Please help me to reproduce the issue. Okay, by watching packet counts and counting to 16/17, I was able to see the following (this happens after I loaded the original page and then waited): 1. Server sends client FIN,ACK on connection #1. 2. Client sends server ACK on connection #1. 3. Form posted in Safari sends HTTP POST to server on connection #1. 4. Client sends FIN,ACK on connection #1. 5. Client sends SYN on new connection #2. 6. Server sends *6* RST on connection #1. 7. Server sends SYN,ACK on connection #2. 8. Client sends ACK on connection #2. 9. Client resends HTTP POST to server on connection #2. Yeah, something weird is definitely going on. Does it make a difference that I'm using a wireless connection instead of a physical ethernet cable? Does it make a difference that I'm hitting a site on the internet (where TCP/IP is involved and I'm going through a firewall) versus hitting a local server (where only TCP may be involved)?
I'm on a wireless connection, and had the problem consistently until we disabled keep-alive. Also, the problem (for us, at least) was when people would access our site over the Internet. I did manage to duplicate the problem once locally, using lighttpd as the server. I'm in the middle of a bunch of stuff right now, but when my plate clears up I'll try and get that environment going again, to test.
Thinking out loud, the goal should be an Objective-C (or C++ or Obj-C++) test program that reproduces the issue consistently (or at least frequently) since that's going to get us as close to mimicking what Safari does, and it will aid Apple in tracking down the issue.
Okay, I'm able to reproduce it using Personal Web Sharing and Attachment 6478 [details] as my CGI script! Interestingly enough, when I follow the same steps on http://validator.w3.org/ that reproduce the bug locally, I don't get the hang. (There are also other differences, like receiving 5 RST packets from validator.w3.org instead of just one from the local web server.) I definitely need a refresher on the TCP/IP protocol to understand what's going on! I'll try to post steps to reproduce here soon (probably tomorrow).
(In reply to comment #32) > Okay, I'm able to reproduce it using Personal Web Sharing and Attachment 6478 [details] [edit] > as my CGI script! Reproduced using shipping Safari 2.0.4 (419.3) on Mac OS X 10.4.8 (8L127). Also reproduced using a locally-built debug build of WebKit r18636 with the above software. This does seem to be an issue with code that sits between WebKit and the network layer.
Awesome news! It was so discouraging to be unable to have anyone on the webkit team reproduce this issue. I hope that this helps you in discovering what the real problem is. I'll keep working to reproduce the problem as well.
(In reply to comment #33) > Reproduced using shipping Safari 2.0.4 (419.3) on Mac OS X 10.4.8 (8L127). > Also reproduced using a locally-built debug build of WebKit r18636 with the > above software. This does seem to be an issue with code that sits between > WebKit and the network layer. Also reproduced with Safari 3.0 (521.31.1) on Leopard build 9A321.
Reopening briefly to get more visibility on webkit-unassigned.
Created attachment 12286 [details] bug-5760-test-files.tar.gz Files used to reproduce this bug. See Comment #38.
Summary ------- There are two issues that I discovered while researching Bug 5760. The first is an inefficiency in the network layer, and the second is the cause of this bug which apparently depends upon the first issue. See the "Notes" section below for more details on each issue. Issue #1 - Foundation classes attempt to use a half-closed connection after a keep-alive connection has expired. Issue #2 - When an HTML form with a file upload is submitted through Safari and a half-closed connection is used (Issue #1), the Foundation classes fail to resend the contents of the file to the web server the second time the form data is posted. Setup Instructions ------------------ The following instructions use the local Apache web server installed for Personal Web Sharing and the current user's ~/Sites/ directory to reproduce the two issues above. 1. Download the bug-5760-test-files.tar.gz file in Attachment 12286 [details]. 2. Extract the tar.gz file to the current user's ~/Sites/ directory. 3. Edit bug-5760.conf to replace "USERNAME" in the <Directory> directive with the current user's username. 4. Move bug-5760.conf to the /etc/httpd/users/ directory on Tiger, or /etc/apache2/other/ on Leopard. (You'll need to use sudo(1) to do this.) 5. Open System Preferences. 6. Click on Sharing under Internet & Network. 7. Start Personal File Sharing. (If it's already been started, stop and start it to pick up the new config file.) Steps to Reproduce ------------------ The following instructions describe how to reproduce Issue #2 above. It will also reproduce Issue #1 if no file is specified in the file upload input, but this is only meaningful if you're capturing a packet trace of the connection(s) using a tool like Ethereal/Wireshark. 1. Close Safari (or WebKit) if it's currently open. 2. Delete the icon database file, or rename it if you want to keep your prized collection of favicons. (This step is a red herring since this bug has nothing to do with the icon database. This step is done to guarantee that a keep-alive connection will be created when Safari attempts to load the favicon.ico file from the web site. In real-life scenarios, <img> tags on the page could create keep-alive connections as well.) 3. Start Safari. 4. Open URL to bug-5760.html (replace "HOSTNAME" with the hostname or IP address of your Mac, and replace "USERNAME" with the current user's username): http://HOSTNAME/~USERNAME/bug-5760.html 5. Quickly pick ANY file to upload in the file upload input before the counter reaches zero. (You have less than 19 seconds.) 6. Wait for the countdown to reach zero and the form to submit itself. Expected Results ---------------- The form should be submitted to the server with the contents of the uploaded file. Actual Results -------------- Submitting the form hangs. When the web server's connection timeout is reached (usually 5 minutes), it will return an internal server error. Regression ---------- These issues have been reproduced with the following software on a PowerBook G4: Mac OS X 10.4.8 (8L127) with Safari 2.0.4 (419.3) and Apache/1.3.33 (Darwin). Mac OS X 10.4.8 (8L127) with ToT WebKit (r18639), Safari 2.0.4 (419.3) and Apache/1.3.33 (Darwin). Mac OS X Leopard (9A321) with Safari 3.0 (521.31.1) and Apache/2.2.3 (Unix). And with the following software on a MacBook Pro Core 2 Duo: Mac OS X 10.4.8 (8N1037) with Safari 2.0.4 (419.3) and Apache/1.3.33 (Darwin). Notes ----- Issue #1 - Foundation classes attempt to use a half-closed connection after a keep-alive connection has expired. NOTE: The information below is based on the behavior I saw in packet traces captured using Ethereal/Wireshark while researching Issue #2. I did not attempt to step through, decompile or write test programs for the Foundation classes to prove or to disprove the following information. Here is a basic outline of what happens: 1. User uses Safari to request a web page with a form. 2. At least one connection to the server is kept alive after the web page, resources (images) and favicon are loaded. 3. User fills out the form. 4. User waits just long enough for the server to close it's half of the kept-alive connection (server sends FIN,ACK; OS X sends ACK), but before OS X closes its half of the connection. 5. User submits the form in Safari. 6. Safari uses Foundation classes to send form data. 7. Server sends an RST packet to reset the connection. 8. Foundation classes open a new connection to the server and resend the form data. The above process works fine in all cases except when a file upload is included in the form (Issue #2). However, note that Firefox 2.0.0.1 (running on the same version of Mac OS X on the same hardware) will close its half of the connection immediately after the server closes its half of the connection, thereby avoiding the inefficiencies of attempting to use a half-closed connection to the server. Issue #2 - When an HTML form with a file upload is submitted through Safari and a half-closed connection is used (Issue #1), the Foundation classes fail to resend the contents of the file to the web server the second time the form data is posted. The outline of what happens is essentially identical to Issue #1, except that (1) a file upload input is included in the form and (2) when the form is resent, the contents of the uploaded file are not sent the second time the form data is sent: 1. User uses Safari to request a web page with a form that contains a file upload input. 2. At least one connection to the server is kept alive after the web page, resources (images) and favicon are loaded. 3. User fills out the form including the file upload input. 4. User waits just long enough for the server to close it's half of the kept-alive connection (server sends FIN,ACK; OS X sends ACK), but before OS X closes its half of the connection. 5. User submits the form in Safari. 6. Safari uses Foundation classes to send form data including the contents of the uploaded file. 7. Server sends an RST packet to reset the connection. 8. Foundation classes open a new connection to the server and resend the form data, but the contents of the uploaded file are not sent the second time. 9. If Safari and the server are left alone, the server waits until its connection timeout expires (commonly 300 seconds for a default Apache installation; see Timeout directive in httpd.conf), then sends an Internal Server Error since it never received the contents of the uploaded file in the second request. This is the original reason this bug was filed. Note that I've only been able to reproduce Issue #2 using a local Apache web server. When I attempt to duplicate the above steps using an external site (such as the file upload form on http://validator.w3.org/), there are five RST packets sent in step 7, and the contents of the uploaded file are sent in Step 8. Finally, if you have trouble reproducing the issue: - You can try playing with the 'fudgeFactor' variable in bug-5760.html. An integer value from 2 to 5 (seconds) should work for most configurations. - The easiest way to make sure you're reproducing the bug is to install Wireshark through fink or MacPorts (formerly DarwinPorts). While capturing packets, watch for a tell-tale increase of two in the TCP packet count after the 15-second keep-alive connection expires, then submit the form manually immediately after that. (NOTE: Installing either of these requires installing Xcode and X11 on your Mac. I tried building Wireshark using GTK+ for OS X, but it crashes in font code in Cairo.) - Sometimes the bug is reproducible repeatedly for a while without stopping Safari. However, if it stops becoming repeatable, stop Safari, delete the icon database, than restart Safari (e.g., follow the instructions provided above).
(In reply to comment #36) > Reopening briefly to get more visibility on webkit-unassigned. And closing again as RESOLVED/INVALID since this is mostly like a Foundation bug and will be followed-up by an Apple engineer internally. See Comment #28 for the Radar number.
*** Bug 14195 has been marked as a duplicate of this bug. ***
For what it's worth: Issue #1 is being tracked as <rdar://problem/4102132> Issue #2 is being tracked as <rdar://problem/4876179>
(In reply to comment #38) > Issue #2 - When an HTML form with a file upload is submitted through Safari and > a half-closed connection is used (Issue #1), the Foundation classes fail to > resend the contents of the file to the web server the second time the form data > is posted. (In reply to comment #41) > Issue #2 is being tracked as <rdar://problem/4876179> This issue should be fixed as of Mac OS X 10.5.5. If anyone can confirm this, I'd appreciate it.
(In reply to comment #42) > This issue should be fixed as of Mac OS X 10.5.5. If anyone can confirm this, > I'd appreciate it. I have several clients that also experience this problem. They will be updating to 10.5.5 today. Will report back if the issue remains.
(In reply to comment #43) > (In reply to comment #42) > > This issue should be fixed as of Mac OS X 10.5.5. If anyone can confirm this, > > I'd appreciate it. > > I have several clients that also experience this problem. They will be > updating to 10.5.5 today. Will report back if the issue remains. Any update, Steve? Thanks!
> Any update, Steve? Thanks! Unfortunately, I can confirm that this issue remains in 10.5.5. Even more unfortunate is that the issue is exhibited on one of our internal sites, but not in the test provided in comment #38 above. In other words, the test provided works fine, but I'm still having this issue. I'm going to try and do some more testing in the next few days to see if I can nail it down anymore.
(In reply to comment #45) > > Any update, Steve? Thanks! > > Unfortunately, I can confirm that this issue remains in 10.5.5. Even more > unfortunate is that the issue is exhibited on one of our internal sites, but > not in the test provided in comment #38 above. In other words, the test > provided works fine, but I'm still having this issue. I'm going to try and do > some more testing in the next few days to see if I can nail it down anymore. Thanks for the update! You'll want to use a packet sniffer like Wireshark (formerly Ethereal) to capture the network traffic when the bug occurs to determine what's really going on. Note that only Issue #2 from Comment #38 and Comment #41 is fixed. Issue #1 still remains.
Created attachment 27484 [details] Wireshark trace of issue under OS10.5.6/Safari 3.2.1 (In reply to comment #46) > > Unfortunately, I can confirm that this issue remains in 10.5.5. Are there any more updates on this issue? I am still seeing it in OSX 10.5.6 with Safari 3.2.1 (5525.27.1) > Thanks for the update! You'll want to use a packet sniffer like Wireshark > (formerly Ethereal) to capture the network traffic when the bug occurs to > determine what's really going on. I've attached a Wireshark trace (safari_bug5760_OSX10.5.6-Safari5525.27.1.gz) showing that both issues are still occuring using the above noted OSX/Safari versions. The initial GET is packet 6 (0.001530), replied to in packets 8-15 (0.734507) with a 5 second keep-alive. The keep-alive timeout results in the server closing the connection in packet 21 (5.857426), acknowledged by Safari in packet 22 (5.857578), but it still attempts to do a POST on it starting in packet 23 (11.976699), with the consonant resets, resync and re-POST that stalls by packet 35 (11.979735).
(In reply to comment #47) > Created an attachment (id=27484) [review] > Wireshark trace of issue under OS10.5.6/Safari 3.2.1 > > (In reply to comment #46) > > > Unfortunately, I can confirm that this issue remains in 10.5.5. > > Are there any more updates on this issue? I am still seeing it in OSX 10.5.6 > with Safari 3.2.1 (5525.27.1) > > > Thanks for the update! You'll want to use a packet sniffer like Wireshark > > (formerly Ethereal) to capture the network traffic when the bug occurs to > > determine what's really going on. > > I've attached a Wireshark trace (safari_bug5760_OSX10.5.6-Safari5525.27.1.gz) > showing that both issues are still occuring using the above noted OSX/Safari > versions. The initial GET is packet 6 (0.001530), replied to in packets 8-15 > (0.734507) with a 5 second keep-alive. The keep-alive timeout results in the > server closing the connection in packet 21 (5.857426), acknowledged by Safari > in packet 22 (5.857578), but it still attempts to do a POST on it starting in > packet 23 (11.976699), with the consonant resets, resync and re-POST that > stalls by packet 35 (11.979735). Please file a Radar on <https://bugreport.apple.com/>. I appreciate the follow-up on this issue, but there's nothing that may be fixed in WebKit to resolve this issue. Thanks!
Filed in Radar: Bug ID# 7077923 https://bugreport.apple.com/cgi-bin/WebObjects/RadarWeb.woa/81/wo/LbLkeTB7chj7RpdWRTbyTw/15.56
This is a very serious problem first reported in 2005 and still not fixed in 2010 in Snow Leopard. I understand that it's a problem with the OS level TCP/IP stack. But seeing as the other team responsible for that library has not provided a fix in a timely manner it is up to you to work around the issue. Use your own TCP/IP stack just like Firefox does. Use the stack from Firefox if you want. Please fix this now for all Mac OS that have Safari 4 (including Tiger). We have a WebObjects application that we distribute to many customer intranets. We do not want to be beholden to a brittle Apache configuration that could be ever changing on their end. Here are some additional facts for this issue: 1) Safari 3.2.1 and 4.x have the intermittent hang problem when uploading multipart/mime data to the vanilla Apache 2.2.11 that ships with Snow Leopard client. 2) If I turn off keepalive in the Apache 2 configuration file "BrowserMatch Safari nokeepalive" - Safari no longer hangs. 3) When a hang in safari occurs, simply clicking the submit button of the form a second time always satisfies the issue. But you don't want to have to tell your users to "click it again if it seems slow". 4) Safari 3.2.1 and 4.x never hang when uploading multipart/mime data to the vanila apache 1.3.41 that ships with Tiger client. I double checked the apache configuration file and it appears that keepalive is left on there by default. In summary, this issue is just starting to bite us in 2010 because we just decided to upgrade our development machines to Snow Leopard. Previously we had been using Tiger and thus bypassed the whole 10.5 OS release. Other people have been bitten for over five years. You must take matters into your own hands and fix it in WebKit for the sake of the innocent and loyal Macophiles out there. For now we have used an elaborate workaround based on other's insight. We use javascript to fire a dummy form POST on the mousedown event of the submit button. This dummy action hits a DirectAction on the WebObjects side which crafts a very special dummy reply to close the http session. Since the session is closed by the time the javascript event propagation gets to "form.onsubmit" Safari must renegotiate a clean new http connection with Apache that never fails to send the multipart-mime data. The fact that some issue related to this on is in radar with id = 7077923 does not make me feel warm and fuzzy. I have no access to that ticket and have no idea if any progress is being made. What am I supposed to do? make yet another ticket? I don't think so, that's why I'm posting here, the only place that makes sense. At the very least the status of INVALID should be changed to MOVED or WONTFIX. This is a very real and very serious problem. It doesn't really matter that its part of the TCP/IP stack that WebKit is using, it's hurting the end users. You can choose a different TCP/IP stack and solve the problem or give us a way to pass on critical information to the team responsible for the TCP/IP stack.
(In reply to comment #50) > The fact that some issue related to this on is in radar with id = 7077923 does > not make me feel warm and fuzzy. I have no access to that ticket and have no > idea if any progress is being made. What am I supposed to do? make yet another > ticket? I don't think so, that's why I'm posting here, the only place that > makes sense. Actually, duplicate bug reports from different developers is an indication about how wide-spread this issue is. I would encourage you to file a bug report on <https://bugreport.apple.com/>, even though it will be returned as a duplicate. If you don't have an Apple Developer Connection (ADC) account, you may create a free "online" account using <https://connect.apple.com/>. > At the very least the status of INVALID should be changed to MOVED or WONTFIX. > This is a very real and very serious problem. It doesn't really matter that its > part of the TCP/IP stack that WebKit is using, it's hurting the end users. You > can choose a different TCP/IP stack and solve the problem or give us a way to > pass on critical information to the team responsible for the TCP/IP stack. The WebKit project uses RESOLVED/INVALID status for bugs migrated into Apple's internal bug tracker (Radar) because the issue is not in WebKit itself. It does not mean that it's not a valid bug.
Ok I've created a duplicate radar ticket with number: 7547183
(In reply to comment #52) > Ok I've created a duplicate radar ticket with number: 7547183 Thanks!
I found out at some point that nginx (the web server that github runs on) disabled HTTP keepalive because of this issue. This makes interaction slower in WebKitGTK+, because we pretend to be Safari. http://mailman.nginx.org/pipermail/nginx/2010-October/023131.html
I just found old workaround code for this in our app. Can you tell whether (or rather: with what release) this bug has been fixed by Apple? There doesn't seem to be a way to see the radars unless for authors. Thanks!
(In reply to svoop_k6ed49fz2s from comment #55) > I just found old workaround code for this in our app. Can you tell whether > (or rather: with what release) this bug has been fixed by Apple? There > doesn't seem to be a way to see the radars unless for authors. Thanks! There were two bugs per comment #38 and comment #41. See comment #42 for the macOS release where the second bug was fixed. I haven’t tried to reproduce the first bug in years.