I am using Safari 5523.10 on PPC 10.5 A nightly from a week ago also has this same issue. iPhone does not seem to have this issue. Intel MacBook also has same issue, that is my entire test bed. http://newgeo.com/web/safari/enctype.ws Given the test case above, you can view source to see the html, only difference in each form button is the form enctype. Each button tests a different version. There is server side code that injects : HTTP/1.0 302 Moved Temporarily Server: WebSiphon/2.0 MIME-Version: 1.0 Location: http://newgeo.com/web/safari/done.ws Depending on the enctype, one will honor the 302 immediately, the other will stall for the difference of the two time stamps below, even though the url bar in Safari has already changed: ===== 2007 11 27 ===== 20:11:49 GMT-08:00 ===== ===== 2007 11 27 ===== 20:12:46 GMT-08:00 ===== Near 60 second stall, this is repeatable. I have also attached tcp dump data of each case, one is stalls.txt and the other is works.txt, each file should be self explanatory.
Created attachment 17564 [details] tcp data of stalling case
Created attachment 17565 [details] tcp data of working case
Additional browsers tested: Firefox 2.0.0.9 Mac OS X 10.5 PPC Unknown Windows Explorer version Above browsers do not have any stalling issues from my rudimentary tests.
Comment on attachment 17564 [details] tcp data of stalling case Another instance of a GET request with an invalid Content-Type header that came after a 302 from a POST request. >POST /web/safari/enctype.ws HTTP/1.1 >User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-us) AppleWebKit/523.10 >.3 (KHTML, like Gecko) Version/3.0.4 Safari/523.10 >Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryu2Bf8fsi9aZ5 >exY0 >Referer: http://newgeo.com/web/safari/enctype.ws >Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/pl >ain;q=0.8,image/png,*/*;q=0.5 >Accept-Language: en-us >Accept-Encoding: gzip, deflate >Content-Length: 163 >Connection: keep-alive >Host: newgeo.com > >------WebKitFormBoundaryu2Bf8fsi9aZ5exY0 >Content-Disposition: form-data; name="a" > >- Send as multipart/form-data - >------WebKitFormBoundaryu2Bf8fsi9aZ5exY0-- >HTTP/1.0 302 Moved Temporarily >Server: WebSiphon/2.0 >MIME-Version: 1.0 >Location: http://newgeo.com/web/safari/done.ws > ><form action="enctype.ws" method="post" enctype="application/x-www-form-urlenc >oded"> > <input name="a" type="submit" value="- Send as application/x-www-form-urlenco >ded -"><br> ></form> > > ><form action="enctype.ws" method="post" enctype="multipart/form-data"> > <input name="a" type="submit" value="- Send as multipart/form-data >-"><br> ></form> >GET /web/safari/done.ws HTTP/1.1 >User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-us) AppleWebKit/523.10 >.3 (KHTML, like Gecko) Version/3.0.4 Safari/523.10 >Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryu2Bf8fsi9aZ5 >exY0 >Accept-Encoding: gzip, deflate >Referer: http://newgeo.com/web/safari/enctype.ws >Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/pl >ain;q=0.8,image/png,*/*;q=0.5 >Accept-Language: en-us >Connection: keep-alive >Host: newgeo.com
*** This bug has been marked as a duplicate of 16082 ***
BTW, thanks for the excellent bug report!
You are welcome. Forgive my ignorance... Does a status of resolved mean this has been fixed in a nightly, and I am to take this as a nod to download the nightly and perform QA tests on the resolution? Is there any more detail, just to satisfy my curiosity, as to what is going on, and why this happens? Does it affect other entypes or just the one I noticed? I can certainly look into changing the enctype on my apps that use it in order to work around this, however, I would like to know what my options are. Thank you. (All apple products should have bugzilla, this is a great example of how this system works to better the end users experience)
(In reply to comment #7) > Forgive my ignorance... Does a status of resolved mean this has been fixed in a > nightly, and I am to take this as a nod to download the nightly and perform QA > tests on the resolution? > > Is there any more detail, just to satisfy my curiosity, as to what is going on, > and why this happens? Does it affect other entypes or just the one I noticed? > I can certainly look into changing the enctype on my apps that use it in order > to work around this, however, I would like to know what my options are. Since the bug is in an internal framework (probably CFNetwork), it's not a part of WebKit and thus can't be fixed with nightly builds. Unfortunately, the visibility into these types of bugs ends with the bug being put into Radar. Apple doesn't comment on future releases, so it's hard to say when this bug will get fixed. Please know that the correct parties are now aware of the bug, though. You can test the behavior for yourself by changing the encoding type on the form and watching what Safari (via CFNetwork) sends to the web server. I *think* this only affects multipart/form-data encoding, but I'm not sure. It would be easy for you to test, though, as I mentioned.