[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bugs-dist
Subject:    [Bug 62425] Lowercasing/normalising URLs breaks some non-compliant
From:       "Petter E.Stokke" <gibreel () gibreel ! net>
Date:       2003-09-14 23:24:45
[Download RAW message or body]

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
     
http://bugs.kde.org/show_bug.cgi?id=62425     




------- Additional Comments From gibreel@gibreel.net  2003-09-15 01:24 -------
Subject: Re:  Lowercasing/normalising URLs breaks some
	non-compliant protocols

> However, rfc2397 states they are subject to decoding. That means the data url  
>   
> data:,%31%30%30  
>   
> should be decoded to  
>   
> data:,100  
>   
> Interpreting the definition of KURL::RawURI, this won't happen. If this is the  
> case (and I haven't misinterpreted it), data urls need another URIMode like  
> RawDecodeable.  

I'm not sure about the definition, but the RawURI implementation, at
least, does decode its input, because ed2k, sig2dat and magnet URIs want
the same behaviour as data. In fact, I don't think there's ever going to
be a situation where we don't want to decode %xx constructs.
  
> [...] I propose that with the exception of protocol() and url(), all  
> component-retrieval methods return an empty string on raw urls.

This might cause problems with mailto URIs, though - the old behaviour
would return the email address as path(). In my implementation, they're
treated as RawURI, but with extra processing for the host part, which is
the reasoning behind putting it in path() in both cases. Then again,
it's perfectly possible to make this behaviour exclusive to mailto.

> As url() returns the url with encodings left in place, maybe there should be an
> additional function urlDecoded().

Isn't that pretty much what prettyURL() does?

> Petter: Please include "data" in the list for autodetection 

Done.
[prev in list] [next in list] [prev in thread] [next in thread]