Bug 16166 - Depending on form action enctype, safari stalls badly on 302 redirect
Summary: Depending on form action enctype, safari stalls badly on 302 redirect
Status: RESOLVED DUPLICATE of bug 16082
Alias: None
Product: WebKit
Classification: Unclassified
Component: Forms (show other bugs)
Version: 523.x (Safari 3)
Hardware: Macintosh OS X 10.5
: P2 Normal
Assignee: Nobody
URL: http://newgeo.com/web/safari/enctype.ws
Keywords:
Depends on:
Blocks:
 
Reported: 2007-11-27 20:19 PST by scott
Modified: 2007-11-29 00:02 PST (History)
0 users

See Also:


Attachments
tcp data of stalling case (16.72 KB, text/plain)
2007-11-27 20:20 PST, scott
no flags Details
tcp data of working case (13.01 KB, text/plain)
2007-11-27 20:21 PST, scott
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description scott 2007-11-27 20:19:57 PST
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.
Comment 1 scott 2007-11-27 20:20:43 PST
Created attachment 17564 [details]
tcp data of stalling case
Comment 2 scott 2007-11-27 20:21:02 PST
Created attachment 17565 [details]
tcp data of working case
Comment 3 scott 2007-11-27 20:24:04 PST
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 4 David Kilzer (:ddkilzer) 2007-11-28 05:23:38 PST
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
Comment 5 David Kilzer (:ddkilzer) 2007-11-28 05:25:07 PST

*** This bug has been marked as a duplicate of 16082 ***
Comment 6 David Kilzer (:ddkilzer) 2007-11-28 05:32:56 PST
BTW, thanks for the excellent bug report!

Comment 7 scott 2007-11-28 15:18:58 PST
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)
Comment 8 David Kilzer (:ddkilzer) 2007-11-29 00:02:18 PST
(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.