Bug 17868 – 303 See Other redirect not handled correctly for POST with multipart/form-data content-type

• Component: Page Loading
• Status: RESOLVED FIXED

[Ryan Grove]

According to RFC 2616, when a 303 See Other redirect is received in response to a POST request, the browser should retrieve the new URI using a GET request.

In Safari 3 and WebKit nightly 31055, when following a redirect received in response to a POST request with a content-type of "multipart/form-data", WebKit sends a malformed multipart/form-data POST request to the new location rather than sending a GET request as it should.

[Mark Rowe (bdash)]

There's already a bug about the first part of the issue (when a 303 See Other redirect is received in response to a POST request, the browser should retrieve the new URI using a GET request).  I don't believe that it covers the specific bug with malformed POSTs though.  Can you please provide a URL that demonstrates this issue?

[Ryan Grove]

(In reply to comment #1)
> Can you please provide a URL that demonstrates this issue?

Here you go: http://pieisgood.org:9000/

After you upload a file, the server will redirect to /

Safari appears to follow the redirect by sending a multipart/form-data POST request with no body, which results in a server error. Firefox and IE correctly make a GET request.

[Sean McMains]

We have stumbled across what looks like a very similar issue, only with a 302 response. This breaks the functionality of the Magnolia CMS when used under OS X 10.5.

To reproduce:

1. Log into http://demoauthor.magnolia.info/ with superuser/superuser
2. Double-click the "mailform" page icon to open that page
3. Click the green "New" button near the bottom of the center column to open the new paragraph window
4. In the new paragraph window, select any paragraph type

Expected result (and actual result under OS X 10.4):

New edit window appears:

Actual Result under OS X 10.5:

Magnolia returns an error due to incorrect form data: java.io.IOException: Corrupt form data: premature ending

----

We stuck a sniffer on the wire to see what Safari was sending, and sure enough, it's sending a Post with Content-Type: multipart/form-data, but no actual form data included.

I'm including the traffic logs for both a successful request under 10.4 and an unsuccessful one under 10.5.

[Sean McMains]

Created attachment 20410 [details]
Traffic Between Safari under OS X 10.4 and Magnolia

Represents a successful transaction between browser and server.

[Sean McMains]

Created attachment 20411 [details]
Traffic Between Safari under OS X 10.5 and Magnolia

An unsuccessful transaction between Safari and the server.

[Alexey Proskuryakov]

I do not think that issues with a 302 response necessarily have the same root cause as 303 ones. It would be better to track them separately to reduce confusion.

In any case, such issues tend to be in closed source system frameworks below WebKit. Could you please file them at http://bugreport.apple.com, so that Apple engineers working on said system frameworks could investigate them?

[Sean McMains]

Ok, I've submitted a bug report to Apple now for the 302 issue. Thanks for the pointer!

[Brady Eidson]

Sean, I just tried to reproduce this issue to see if it was still around in the latest Leopard update, and it seems the Magnolia site has been changed from the steps you describe...  can you confirm a way the issue can still be reproduced?

[Sean McMains]

Hmm, the Magnolia site still looks the same to me -- perhaps I didn't describe the steps well.

Good news, however. With Safari 3.1.2 and OS X 10.5.4, I no longer see the problem. Looks like the lads at Apple have cleaned up the issue, at least for the 302 response.

[Brady Eidson]

Well, I claim the Magnolia site had changed because I saw no paragraph window or paragraph type selection, so I couldn't even tell if I was reproducing a bug or demonstrating the bug was no longer there!  :)

If you think the issue has been resolved in the latest updates (10.5.4 had some changes to CFNetwork, the underlying networking library that was likely the culprit here), then please close the bug as FIXED.

[Sean McMains]

Hi Brady,

I'd be happy to close the bug, but the only option I appear to have is "Leave as UNCONFIRMED".

Sean

(In reply to comment #10)
> If you think the issue has been resolved in the latest updates (10.5.4 had some
> changes to CFNetwork, the underlying networking library that was likely the
> culprit here), then please close the bug as FIXED.
>