Bug 16166 – Depending on form action enctype, safari stalls badly on 302 redirect

• Component: Forms
• Status: RESOLVED DUPLICATE

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.

[David Kilzer (:ddkilzer)]

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

[David Kilzer (:ddkilzer)]

*** This bug has been marked as a duplicate of 16082 ***

[David Kilzer (:ddkilzer)]

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)

[David Kilzer (:ddkilzer)]

(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.