lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: lynx-dev resolving weird URL types


From: Klaus Weide
Subject: Re: lynx-dev resolving weird URL types
Date: Thu, 13 May 1999 14:19:22 -0500 (CDT)

On Thu, 13 May 1999, Leonid Pauzner wrote:

> Example:  press 'g' and enter xyz://aaa.bbb.cc URL.
> 
> Apparently, lynx will not reject weird URL schemes
> at LYEnsureAbsoluteURL() / LYConvertURL() stage,
> it will try to resolve DNS first.
> 
> Such URL prefixes normally rejected by is_url() in getfile()
> with "Badly formed address" alert message
> but user defined URLs (startfile, etc.) does serve another way.

There are at least two theings that have been broken wrt. URL
recognition:  The first happened not long ago, when the *_URL_TYPE
macros were made into an enum:

typedef enum {
    UNKNOWN_URL_TYPE = 0,

UNKNOWN_URL_TYPE used to be a different value, intentionally different
from 0!  Before, Lynx would recognize xyz://aaa.bbb.cc as an unsupported
URL, which is different from Not-A-URL.  Now it cannot distinguish any
more.

> IMO, LYEnsureAbsoluteURL() should filter out such urls itself. BTW,
> LYConvertToURL() is used by LYEnsureAbsoluteURL() only (not public).
> 
> 
> /*
> **  This function ensures that an href will be
      ^^^^^^^^^^^^^^^^^^^^^
> **  converted to a fully resolved, absolute URL,
> **  with guessing of the host or expansions of
> **  lead tildes via LYConvertToURL() if needed,
> **  and tweaking/simplifying via HTParse().  It
> **  is used for LynxHome, startfile, homepage,
> **  an 'g'oto entries, after they have been
> **  passed to LYFillLocalFileURL(). - FM
> */
> PUBLIC void LYEnsureAbsoluteURL ARGS2(

No, it doesn't ensure this anymore.  This has been broken quite
a while ago.   It is this bit in LYConvertToURL() that makes 
LYEnsureAbsoluteURL() violate its stated purpose:

                } else {
                  /* RW 1998Mar16  Restore AllocatedString to 'old_string' */
                    StrAllocCopy(*AllocatedString, old_string);
                }

That change was made to re-offer the original string after an invalid
URL is entered at a 'g' etc. prompt.  But it gets in the way of the main
purpose of LYEnsureAbsoluteURL().

The best way to resove this would be to add a third argument to
LYEnsureAbsoluteURL(), for passing back the suggested string for re-
offering at the prompt.  All places where LYEnsureAbsoluteURL() is
called, except the one in mainloop() for 'g' handling, would just
ignore the value (or pass a NULL pointer, to say "I don't need this.")

These two things should be fixed before other tweaks in this area;
maybe then the other changes won't be needed at all.

   Klaus



reply via email to

[Prev in Thread] Current Thread [Next in Thread]