Summary: | Depending on form action enctype, safari stalls badly on 302 redirect | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | scott | ||||||
Component: | Forms | Assignee: | Nobody <webkit-unassigned> | ||||||
Status: | RESOLVED DUPLICATE | ||||||||
Severity: | Normal | ||||||||
Priority: | P2 | ||||||||
Version: | 523.x (Safari 3) | ||||||||
Hardware: | Mac | ||||||||
OS: | OS X 10.5 | ||||||||
URL: | http://newgeo.com/web/safari/enctype.ws | ||||||||
Attachments: |
|
Description
scott
2007-11-27 20:19:57 PST
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. |