[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 bugzilla-request-daemon at opendarwin.org
Mon Sep 11 10:45:51 PDT 2006

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)

Attachment 10501: proposed patch

------- 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
> 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.

More information about the webkit-reviews mailing list