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