On Jan 25, 2005, at 12:21 AM, Darin Fisher wrote:
Yes, when you generate a nsIURI from a URI string, the result is canonicalized. In other words, we fixup the default port, lowercase the hostname (or handle IDN), convert to the "origin charset" if necessary, and apply escaping rules, etc. One thing we do not do is unescape anything. So, "http://foo/%41"; is not treated as equal to "http://foo/A";. In practice, this hasn't been much of an issue since web servers treat them equally. It's possible that we might want to unescape anything that doesn't need to be escaped as part of our canonicalization process.
I think it would be nice to have a function/method that allowed embedders to have access to the functions that do the canonicalization (that's a mouth full), and also "undo" it. If one ever hopes to be able to do comparisons against the current location displayed by the browser, one needs to be able to do so on common ground. While creating a temporary URI on the stack to do this comparison is a workable solution, having to create an object to do comparison seems a little heavy-handed. Let me explain my use case a bit:
My widget keeps track of its own "value", which is the current location being displayed in the embedded browser. To be able to keep this up to date, I must implement nsIWebProgressListener, and respond to onLocationChange(). I will be getting a URI, and asking the URI for a string representation of its location, which will be "canonicalized", as you say. At some point, i want to do a comparison to avoid reloading of the page when it is unnecessary and undesired (the reasoning for this is specific to the larger application I am working in). Plus, it must be possible to read the current location as a property, which requires I return the canonicalized, which really seems like something that shouldn't be exposed to the end user. It'd be nice to be able to un-escape certain sequences.
Does that seem like a valid use case? Unfortunately, I can't get too detailed as I am under a pretty strict NDA on this project. In the context of this application, these requirements are reasonable.
Thanks.
J
_______________________________________________ mozilla-embedding mailing list [email protected] http://mail.mozilla.org/listinfo/mozilla-embedding
