Bug 17868 - 303 See Other redirect not handled correctly for POST with multipart/form-data content-type
Summary: 303 See Other redirect not handled correctly for POST with multipart/form-dat...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Page Loading (show other bugs)
Version: 528+ (Nightly build)
Hardware: Mac OS X 10.5
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-03-15 17:59 PDT by Ryan Grove
Modified: 2008-07-07 09:51 PDT (History)
4 users (show)

See Also:


Attachments
Traffic Between Safari under OS X 10.4 and Magnolia (3.72 KB, text/plain)
2008-04-08 14:09 PDT, Sean McMains
no flags Details
Traffic Between Safari under OS X 10.5 and Magnolia (3.94 KB, text/plain)
2008-04-08 14:10 PDT, Sean McMains
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ryan Grove 2008-03-15 17:59:59 PDT
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.
Comment 1 Mark Rowe (bdash) 2008-03-15 18:09:06 PDT
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?
Comment 2 Ryan Grove 2008-03-17 20:36:39 PDT
(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.
Comment 3 Sean McMains 2008-04-08 14:08:04 PDT
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.
Comment 4 Sean McMains 2008-04-08 14:09:36 PDT
Created attachment 20410 [details]
Traffic Between Safari under OS X 10.4 and Magnolia

Represents a successful transaction between browser and server.
Comment 5 Sean McMains 2008-04-08 14:10:31 PDT
Created attachment 20411 [details]
Traffic Between Safari under OS X 10.5 and Magnolia

An unsuccessful transaction between Safari and the server.
Comment 6 Alexey Proskuryakov 2008-04-08 23:15:09 PDT
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?
Comment 7 Sean McMains 2008-04-09 07:26:13 PDT
Ok, I've submitted a bug report to Apple now for the 302 issue. Thanks for the pointer!
Comment 8 Brady Eidson 2008-07-03 21:51:33 PDT
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?
Comment 9 Sean McMains 2008-07-07 07:33:59 PDT
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.
Comment 10 Brady Eidson 2008-07-07 09:16:29 PDT
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.
Comment 11 Sean McMains 2008-07-07 09:49:26 PDT
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.
>