[Webkit-unassigned] [Bug 41462] Move parseDataUrl() from CURL into ResourceHandle

[bugzilla-daemon at webkit.org]

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





--- Comment #3 from Darin Adler <darin at apple.com>  2010-07-01 11:27:10 PST ---
(From update of attachment 60240)
I’m not so comfortable with putting this function into the cross platform file because it's used by two back ends. There are many other back ends that don't use it. Should the other back ends be using it too? Is there any other place we could put it?

Naming the function "parse" seems wrong. Parsing is part of what it does, but it actually performs the loading as well. I think the name should be loadDataURL or handleDataURL. The word "parse" gives the sense of something that would output a parsed result, not something that would make actual loading-related calls to the client.

The parseDataURL function should not have a return value. Callers don't look at it.

It should be parseDataURL, not parseDataUrl.

Calling latin1() twice on the same string seems like a mistake. That ends up allocating a CString twice.

Does latin1() handle non-ASCII characters in the way that's correct for this function? Failing as it should? Is there a test case covering that?

I'm surprised that the reinterpret_cast works reliably. What makes the endianness always work out correctly?

The assertion about the URL's scheme should be a protocolIs assertion, not a custom startsWith call.

What data URL test cases do we have?

The ResourceResponse be populated with more, including the URL and the content length as expectedContentLength.

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