[webkit-dev] Changing the implementation of KURL

[Darin Fisher]

On Sat, Jan 28, 2012 at 6:01 PM, Adam Barth <abarth at webkit.org> wrote:

> On Sat, Jan 28, 2012 at 5:51 PM, Benjamin Poulain <benjamin at webkit.org>
> wrote:
> > On Sat, Jan 28, 2012 at 4:59 PM, Brett Wilson <brettw at chromium.org>
> wrote:
> >> So to clarify, I think we need to keep the current architecture.
> >> Obviously WebKit needs a URL class that uses its String class, so
> >> WTFURL would probably be a wrapper around some core library for WebKit
> >> to use. Chromium would rewrite our GURL class to use the same core
> >> library and keep std::strings (we don't want all our browser-level
> >> code to have to convert std::string -> WTF::String just like today we
> >> don't want to do the inverse in WebKit).
> >
> > I don't really get this point. With WTF linked statically, no matter
> > how "largish" WTF, it will not cost much to use.
> >
> > You say you don't want to convert std::string->WTF::String and
> > WTF::String at the browser level, but aren't you doing that a lot more
> > with the current code?
> >
> > Parsing valid URL can probably be done without WTF.
> > URL canonicalization is frequent in WebKit and I would think using
> > String directly is a good idea. Same for modifying a URL.
>
> GURL abstracts the underlying storage so that the canonicalized URL is
> written directly into the proper type.  As far as I can tell, there
> isn't much advantage to WTFURL committing to a particular string type.
>
> > Chromium is the only ports that use the same URL Class in the whole
> > stack. And it seems you do not want any dependencies on WTF. Maybe an
> > alternative is to change this and convert KURL->GoogleURL on platform
> > boundaries like the other ports?
>
> My guess is you won't be able to convince fishd to use different URL
> libraries at different layers in Chromium.  There's a long history of
> that causing security vulnerabilities, both in Firefox and in Safari.
>
>
Right.  In Firefox, the problem was that the cookie code used some
hand-rolled
string parsing code instead of reusing the URL parsing code.  That resulted
in
a subtle bug that could be exploited to steal cookies.  In Safari's case, I
believe
it was caused by differences between CFNetwork and KURL.

If CFNetwork exposed an API to its URL parser, then it would be super wise
for
any port of WebKit using CFNetwork to reuse the same URL parser.

-Darin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20120128/24b9eb82/attachment.html>