[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:       Leo Savernik <l.savernik () aon ! at>
Date:       2003-09-14 22:12:22
[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 l.savernik@aon.at  2003-09-15 00:12 -------
I may add my own wisdom here regarding data urls (rfc2397).  
  
data urls don't comply with [rfc1738, 3.1] at all, they have no host part and  
no path. Therefore, *everything* has to be treated literally.  
  
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 also think it's a bad idea to put the raw url into the path variable. The  
rationale is that for data urls, there is no such thing that is even remotely  
comparable to a path. DOM's HTMLAnchorElement::pathname, however, gets  
initialized with whatever KURL::path() returns which would be total crap in the  
case of data urls. But Javascript applications expect a valid pathname here  
(Mozilla, e. g. fills in nothing for pathname on data urls).  
  
Therefore I propose that with the exception of protocol() and url(), all  
component-retrieval methods return an empty string on raw urls. As url()  
returns the url with encodings left in place, maybe there should be an  
additional function urlDecoded().  
  
Petter: Please include "data" in the list for autodetection 
 
	if ( protocol == "ed2k" ) mode = RawURI; 
+       else if ( protocol == "data" ) mode = RawURI; 
	else if ( protocol == "mailto" ) mode = Mailto;
[prev in list] [next in list] [prev in thread] [next in thread]