[webkit-reviews] review requested: [Bug 4872] XMLHttpRequest fails to throw an exception when there is a security violation (mismatching domains) : [Attachment 10501] proposed patch

[bugzilla-request-daemon at opendarwin.org]

Alexey Proskuryakov <ap at nypop.com> has asked  for review:
Bug 4872: XMLHttpRequest fails to throw an exception when there is a security
violation (mismatching domains)
http://bugzilla.opendarwin.org/show_bug.cgi?id=4872

Attachment 10501: proposed patch
http://bugzilla.opendarwin.org/attachment.cgi?id=10501&action=edit

------- Additional Comments from Alexey Proskuryakov <ap at nypop.com>
(In reply to comment #3)
> It looks like this change now tolerates extra arguments for open, but no
longer
> tolerates extra parameters for send. Is that intentional?

  This was a mistake, fixed!

> In general, I'd like to see tests that cover the "extra arguments" behavior
> since we keep tweaking it back and forth.

  Added http/tests/extra-parameters.html

> Does the XMLHttpRequest exception in setDOMException need to have the strange

> pattern where it thows the error without putting the exception code into the
> object? If so, we need a comment at least to explain why.

  Done. The current XMLHttpRequest spec draft does not specify any code for the
exception (actually, it does not even specify that an exception should be
thrown). And Firefox doesn't put any exception code either.

> How can those checks of the response headers be turned into asserts? Where is

> the code that guarantees the headers will have that form?

  The string is created in HeaderStringFromDictionary(), LoaderFunctionsMac.mm
in the expected form. Actually, I think that the ResourceLoader interface
should be changed to pass this information without serialization.