On Thu, Oct 15, 2009 at 11:45 AM, Jeremy Orlow <[email protected]> wrote:
> On Thu, Oct 15, 2009 at 11:33 AM, Michael Nordman <[email protected]>wrote: > >> >> >> On Wed, Oct 14, 2009 at 4:42 PM, Darin Fisher <[email protected]> wrote: >> >>> On Wed, Oct 14, 2009 at 3:50 PM, Adam Barth <[email protected]> wrote: >>> >>>> On Wed, Oct 14, 2009 at 2:48 PM, Michael Nordman <[email protected]> >>>> wrote: >>>> > As mentioned f2f, this falls apart as soon as Chrome tries to >>>> manufacture a >>>> > security origin. I'm not sure, may already have instances of that in >>>> the >>>> > code base for all I know. >>>> >>>> I'm not sure Chrome is smart enough to manufacture a SecurityOrigin. >>>> There's a lot of tricky work in the canonicalization that we don't >>>> want to duplicate. >>>> >>>> Adam >>>> >>> >>> >>> Agreed, and we shouldn't be in that business. I think for all our use >>> cases, the >>> factory for security origins can be WebCore. >>> >>> Chrome just needs to be able to serialize / de-serialize a security >>> origin, compare >>> them, and possibly access some component parts (though I'm not certain of >>> this >>> requirement). >>> >> >> I think i have use cases for creating an 'origin' based on a GURL. >> > > We've talked through these repeatedly and I think we've made good cases > against them. WebCore canonicalizes security origins. At the moment, we > never create "security origins" in Chrome. > I wasn't implying that webcore's origin code wasn't doing the work, just mentioning the use case of determining an origin based on a url. Something like this could work. // Returns the security origin associated with the given url. (Web)SecurityOrigin (Web)SecurityOrigin::fromURL((Web)URL &url); > You've given some examples of where we _might_ (read: this is vaporware) do > this in the future. For all the use cases I've seen so far, I would > actually propose adding a canonicalizeSecurityOrigin() method to > WebSecurityOrigin that would create a WebCore::SecurityOrigin and then > immediately toString() it. > > What other use cases are there? With each one, please make clear whether > it's something we need today or whether it's something you suspect we'll > need in the future...because I think most if not all of them are in this > second bucket. And I don't want us to code ourselves into a corner, but I > also don't want us to write a bunch of dead code that may be used in the > future. > The use case is tracking usage per-origin in the appcache code. This isn't a hypothetical thing. --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
