[Webkit-unassigned] [Bug 63460] CORS should only deal with request headers set by script authors

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon Jun 27 13:03:05 PDT 2011


https://bugs.webkit.org/show_bug.cgi?id=63460


Alexey Proskuryakov <ap at webkit.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #98735|review?                     |review-
               Flag|                            |




--- Comment #3 from Alexey Proskuryakov <ap at webkit.org>  2011-06-27 13:03:05 PST ---
(From update of attachment 98735)
View in context: https://bugs.webkit.org/attachment.cgi?id=98735&action=review

The implementation cannot work on Mac, because header status will be lost after a round-trip through NSURLRequest (or any other HTTP library request object). WebKit needs this round-trip because it has delegate methods where it informs client applications about requests that are about to be made.

ResourceRequest is ah HTTP level notion, and it shouldn't have any knowledge of Web platform concepts.

Secondly, when we talk about author vs. implementation, where do headers added by client applications fit? It kind of sounds like it's "implementation", but we can't know if those applications use untrusted content to decide which headers to add.

> LayoutTests/ChangeLog:6
> +        CORS should only deal with request headers set by script authors.
> +        https://bugs.webkit.org/show_bug.cgi?id=63460

That's an interesting idea, although it seems somewhat questionable to me. The design principle use to be to avoid hitting servers with anything they couldn't be hit with through form submission, and the new rule deviates from that pretty far.

> Source/WebCore/platform/network/ResourceRequestBase.h:47
> +    enum ResourceRequestHeaderStatus {

Naming nit: I would have liked something like "origination" or "source" more than "status".

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list