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

List:       kde-i18n
Subject:    Re: Fwd: kfm not resolving URI correctly
From:       Torben Weis <weis () troll ! no>
Date:       1999-03-21 21:20:39
[Download RAW message or body]

Hi,

On Sun, 21 Mar 1999, Dawit Alemayehu wrote:

> On Sun, 21 Mar 1999, Torben Weis wrote:
> > Hi,
> > 
> > On Sun, 21 Mar 1999, David Faure wrote:
> > 
> > > This sounds strange to me.
> > > Is "//www.kde.org/" a good URL ?
> > > 
> > > ----- Forwarded message from Hume Smith <hclsmith@glinx.com> -----
> > > 
> > > Date: 	Sat, 20 Mar 1999 22:48:28 -0400 (AST)
> > > subject: kfm not resolving URI correctly
> > > to: faure@kde.org
> > > from: hclsmith@glinx.com (Hume Smith)
> > > 
> > > i had reported this back with kde-1.0, but i guess it got missed.
> > > 
> > > my kfm (calls itself 1.167) still mishandles URIs that lack the scheme (eg \
> > > "//www.kde.org/").  i use these frequently on my site ( \
> > > <URL:http://www.glinx.com/~hclsmith/> ).  This form is permitted by several \
> > > RFCs (eg 1808 section 4 and 2396 section 5.2; also either 1630 or 1738 if \
> > > memory serves) and is recognised by most browsers (Nessie, Messie, and Opera).
> > 
> > Hmmmm, if that is really allowed then I can hack it the state machine of
> > the new KURL ( coming soon ). But I wonder what protocol to choose ?
> > Some magic stuff like looking at the first letters in front of the dot
> > otherwise http ?
> 
> The format stated by Mr. Smith is indeed valid.  If you look at RFC 1738,  the
> scheme specific part of any URL ( BNF expression ) is
> 
> //<user>:<password>@<host>:<port>/<url-path>
> 
> where the scheme ( ftp, http, file etc..) and that particular scheme's parts
> are separated by : 
> 
> <scheme>:<scheme-specific-part>
> 
> So it is a valid URL.  If you would like this can be fixed wihout you hacking
> KURL.  However, this fix in of itself is a hack.  I have been working on
> adding short URL support to kfm and minicli and this can be solved there if you
> wish since it is rarely used ( this is the first time I have heard anyone
> mention this problem !! ).  In fact, unless there is a plan to to change KURL in
> the old kfm to KURL2 then I think it wiil have to be fixed here.  It is just a
> matter of adding another if statement check under slotURLEntered () in kfm and
> the same check in execute() under minicli.C.

I wrote a state machine parser for URLs that will soon come in the KURL
of the HEAD branch. So if we want // stuff there then I have to put it
in there.

I really should read this RFC more often but it is sooooo boring
sometimes.

Bye
Torben

> Cheers,
> Dawit A.
> 


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