HTTP 307 after a 303 after a POST re-sends POST data from the original request. See https://bugs.webkit.org/show_bug.cgi?id=31410 for more discussion and the fix that went in for Mac and Windows. Qt needs to do the same.
Please follow the QtWebKit bug reporting guidelines when reporting bugs. See http://trac.webkit.org/wiki/QtWebKitBugs Specifically: - The 'QtWebKit' component should only be used for bugs/features in the public QtWebKit API layer, not to signify that the bug is specific to the Qt port of WebKit http://trac.webkit.org/wiki/QtWebKitBugs#Component - Add the keyword 'Qt' to signal that it's a Qt-related bug http://trac.webkit.org/wiki/QtWebKitBugs#Keywords
Created attachment 59407 [details] Patch
Comment on attachment 59407 [details] Patch uh, seems like a QtNetwork bug. If you do this change, please add a comment and at best a link to the qt bug report.
(In reply to comment #3) > (From update of attachment 59407 [details]) > uh, seems like a QtNetwork bug. I don't think it is - the reason checking m_method doesn't work for this test is because there are two redirects following an initial POST. The first one is managed successfully: the m_method for the original request is POST, the check detects this and overrides it with GET. For the second redirect, the check sees that m_method is now GET so it doesn't override the method in the newRequest it has created from ResourceHandle::request() (which is still the original value of POST) with GET. So during a redirect chain QNetworkReplyHandler needs to check the httpMethod() or lastHTTPMethod() rather than the m_method, because that will always contain the original request method in a redirect chain. I'll update the changelog with this and use httpMethod() instead - lastHTTPMethod() is Mac-specific really.
Created attachment 59699 [details] Patch
Committed r61875: <http://trac.webkit.org/changeset/61875>