Bug 161860 – Upload FormData isn't sent on redirect

• Status: RESOLVED
• Resolution: INVALID
• Component: WebKit Misc.

[Binyamin]

Upload FormData is sent fine on Ajax post to single /final-request,
but, when having automatic redirect like /validate-token -> /upload-request, no data is sent.

Works fine on Chrome, Firefox and IE. It is regression bug, since on old Safari 5.1 (Windows build) wars fine too.

[Alexey Proskuryakov]

Thank you for the report!

Can you share a test case that reproduces this?

[Binyamin]

I prefer if you can manage without me providing testcase. The issue was found in webservices that aren't public accessible.

[Alexey Proskuryakov]

I didn't really understand what the bug is about (even whether it's about Safari or a separate tool using WebKit). Also what kind of redirect this is - there are different rules for different HTTP codes. But there may be a lot more variables at play that I'm not thinking of right now.

I don't think that there is enough information yet to make progress.

[Binyamin]

The bug is related to latest Safari on Mac.
You can run the simplest test and see that it's Safari regression bug (as working fine on old Safari 5.1). It is always yours (Webkit/Apple dev team) decision to keep Safari buggy or to fix it.

The steps to reproduce the bug:
1. create HTML form with <input type=file>
2. on form post interact with JavaScript and send JavaScript FormData (as POST request) with Ajax to /validate-token
3. for /validate-token make server-side redirect to /upload-request
4 - now you will see that all headers and the posted data are cleared and not sent/redirected to /upload-request while expected.

It works fine (all data sent to /upload-request) on all browsers, except latest Safari (it might be a Safari bug for years).

Resources
FormData https://developer.mozilla.org/en/docs/Web/API/FormData
Ajax https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest

Hope it makes you sence.

[Alexey Proskuryakov]

> 3. for /validate-token make server-side redirect to /upload-request

Please tell us how the server side redirect is implemented. As I said, it is actually correct behavior to remove POST content for some redirect types.

[Binyamin]

I think it was 302 HTTP redirect.

Here Chrome behavior https://chromium.googlesource.com/chromium/src/net/+/master/url_request/url_request_job.cc#48 and 

And https://bugs.chromium.org/p/chromium/issues/detail?id=107159#c1
> ... according to all the HTTP RFCs:  1945, 2068, 2616, and the latest httpbis draft (http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-17).  HTTP 2616 mentions that many browsers rewrite the request in violation of spec.  The latest httpbis spec allows POSTs to be converted to GETs on 302s, which we do, but still requires not rewriting other request types.

[Alexey Proskuryakov]

Yes, rewriting a POST request on a 302 redirect is correct behavior, and per the comment in the Chromium bug that you quoted, Chromium does the same.

Given that you have a case where Safari behaves differently than Chrome, there has to be some other subtlety in your case.

We do have a report about incorrectly rewriting non-POST requests, tracked as bug 46183. But since yours is a POST, that is not what is happening here.

[Anne van Kesteren]

Insufficient information to reproduce.