Re: lynx-dev [PATCH] remove extension to EXTERNAL command, extend CERN rules support for mailto: URLs

[Klaus Weide]

On Thu, 13 Jul 2000, Vlad Harchev wrote:
> On Wed, 12 Jul 2000, Klaus Weide wrote:
> > On Mon, 10 Jul 2000, Vlad Harchev wrote:
> > >   I already told you that quoting every special character with backslash 
> > > in
> > > the URL will work very reliably (I even think it will be the most 
> > > reliable way
> > > beside reimplementing systenm()).
> > 
> > We already have HTQuoteParameter() for UNIX shells, why do you think a
> > different implementation that quotes in a different way (and probably
> > produces less readable strings) but otherwise has the same purpose
> > (pass a string to a shell command) is desirable?
> 
>   I was unaware of this function - it works even better than escaping with
> slash - I have an impression that encoding HTQuoteParameter performs will be
> correctly interpreted even by the broken dos shell.

Actually there seems to be a bug in it, regarding backslash characters.
I'll send a patch in separate mail.


> > > there won't be need for using lynx{prog,exec} with
> > > them, so there is no actual need for all this quoting stuff and for 
> > > allowing
> > > mailto: to be handled by CERN rules.

Still nice to allow it for those who choose to and accept the limitations
(like it works anly on really simple mailto addresses without special
characters, and it can be dangerous).

> > > But anyway, the '*' in "Map blah lynx{prog,exec}://foo *" could be 
> > > substituted 
> > > with quoting special characters applied - this is not difficult, or 
> > > another 
> > > behaviour to be introduced, say asterisk inside single quotes '*', that 
> > > will 
> > > mean "matching URL part, with shell special characters escaped") ). This 
> > > will
> > > allow reliable use of mailto: URLs in cern rules too.
> > 
> > Yes, that is where such a change would belong, not in the interpretation
> > of lynxexec URLs themselves.  Currently the * means just literal 
> > replacement.
> > You can't just change that either; you'd have to invent some new kind of
> > syntax or something like a "MapAndEscape" rule.
> 
>  This is what I as talking about in the paragraph above - I was talking about
> introducing special meaning for "asterisk in single quotes" (not changing the
> semantics associated with "asterisk") - it could mean "the string that matched
> * but escaped for safe passing as single argument for some command via shell".

Well it _does_ change the meaning of asterisk, as well as the meaning of
single quote characters.  In a way that is only useful for lynx{exec,prog}
but not useful for other URL schemes.

Thinking more "generic" (as you advocate :) ), the following would be
more generally useful:

#Transform  URL1  URL2  WHICH_CHARS  HOW  WHAT
#  Like  Map URL1 URL2 , but additionally tranforming hte URL in some way.
#  WHICH_CHARS is one of "unsafeshellchars", "urlunsafechars", "urlreserved" ...
#  HOW is "tosafeshellstring", "urlencode", "urldecode", ...
#  WHAT is "all" (transform whole URL2 after replacing *) or
#          "match" (transform only the characters matched by *)
# For example,
#   http://some.site/*  ->  http://localhost/cgi-bin/handler?url=*
#   would use something like  urlreserved urlencode match, and
#   http://site.that.unnecessarily.redirects/blah?url=http%3A*  ->  http:*
#   would use  urlreserved urldecode match.

Wanna do it? :)

Actually, RULEs could be much more useful if it had a more general
matching mechanism.  Just one '*' is very limiting.  It should have
the full power of apache's mod_rewrite, with regular expressions etc...

Or maybe not.  The reason the mechanism exists at all now is because
the basic code was there anyway (but unused), so I resurrected it
and added some extensions that were useful and didn't require big
changes.  So it's basically limited to what the original CERN libwww
code easily allowed.

   Klaus


; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden