Bug 41156 - Cross origin XMLHttpRequest should log the reason why connection failed
Summary: Cross origin XMLHttpRequest should log the reason why connection failed
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Web Inspector (Deprecated) (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Enhancement
Assignee: Alexey Proskuryakov
URL:
Keywords:
: 41217 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-06-24 07:08 PDT by Stuart Ng
Modified: 2010-07-07 11:25 PDT (History)
7 users (show)

See Also:


Attachments
Actual Packet Capture - Can open with Microsoft Network Monitor or WireShark (1.61 KB, application/octet-stream)
2010-06-24 07:08 PDT, Stuart Ng
no flags Details
first iteration (15.97 KB, patch)
2010-07-02 17:54 PDT, Alexey Proskuryakov
darin: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Stuart Ng 2010-06-24 07:08:33 PDT
Created attachment 59652 [details]
Actual Packet Capture - Can open with Microsoft Network Monitor or WireShark

Send a Cross Origin XHR Post method, and call send with actual data (Tried String and ByteArray)
Get a XHR Status of 0, and eventually get XML Network Error DOM 101.

Cross Origin POST with no data works fine. GET, HEAD Cross Origin also works.

I have reproduced this on Chrome and Safari.

From the packet capture I see HTTP Option being sent with requested method of POST
And we get a response back with Accept-Method of POST as well, but nothing else afterwards

NOte: For POST with no data you never see the Preflight request being sent
Comment 1 Alexey Proskuryakov 2010-06-25 12:29:19 PDT
> Access-Control-Request-Headers: X-Requested-With, Content-Type
< Access-Control-Allow-Headers: X-Requested-With

Is this perhaps the problem?
Comment 2 Stuart Ng 2010-06-25 12:45:21 PDT
Yes this is it! The bug can be closed.

I added "Content-Type to allow-header" and things work.
Comment 3 Alexey Proskuryakov 2010-06-25 13:09:16 PDT
Let's track this as a developer tools issue then. It's really hard to figure out problems like this with WebKit.
Comment 4 Alexey Proskuryakov 2010-07-02 17:29:08 PDT
*** Bug 41217 has been marked as a duplicate of this bug. ***
Comment 5 Alexey Proskuryakov 2010-07-02 17:54:08 PDT
Created attachment 60425 [details]
first iteration
Comment 6 Alexey Proskuryakov 2010-07-06 12:11:19 PDT
Committed <http://trac.webkit.org/changeset/62576>. This actually affected a number of tests!
Comment 7 Alexey Proskuryakov 2010-07-06 13:52:47 PDT
+        if (!m_headers.contains(it->first) && !isOnAccessControlSimpleRequestHeaderWhitelist(it->first, it->second)) {
+            errorDescription = "Request header field " + it->first + " is not allowed by Access-Control-Allow-Methods response header field.";

Oops, that's "Access-Control-Allow-Headers". Corrected in r62592.
Comment 8 WebKit Review Bot 2010-07-06 15:31:25 PDT
http://trac.webkit.org/changeset/62576 might have broken Leopard Intel Debug (Tests)
Comment 9 Adam Barth 2010-07-06 23:57:06 PDT
(In reply to comment #8)
> http://trac.webkit.org/changeset/62576 might have broken Leopard Intel Debug (Tests)

11 hours later and the tree is still busted from this change.
Comment 10 Adam Barth 2010-07-07 00:14:51 PDT
I attempted to clean up your mess in http://trac.webkit.org/changeset/62576

If those expectations are not right, please correct them.

Insert nasty gram about running the tests before committing.
Comment 11 Csaba Osztrogonác 2010-07-07 00:37:18 PDT
(In reply to comment #6)
> Committed <http://trac.webkit.org/changeset/62576>. This actually affected a number of tests!

Qt needed a fix after that, it landed in http://trac.webkit.org/changeset/62602
Comment 12 Alexey Proskuryakov 2010-07-07 09:05:22 PDT
(In reply to comment #10)
> I attempted to clean up your mess in http://trac.webkit.org/changeset/62576

That was <http://trac.webkit.org/changeset/62629>.

Tiger is still broken, I'll investigate ASAP.
Comment 13 Alexey Proskuryakov 2010-07-07 11:25:56 PDT
Fixed Tiger results in <http://trac.webkit.org/changeset/62684> (they are wrong, but not terribly so, and we can't do anything about that anyway).