On Thu, 13 Jul 2000, Klaus Weide wrote:
> 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
> > > > 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).
I don't think that this should have one of the topmost priorities since it's
not that useful then.
> > > > 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? :)
Well, I would like not to do this. At least unlikely in the next 2 weeks.
> 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...
Yes, it's more generic :)
Yes, it would be nice to have them. But even without regexs, I think it
would be nice to hack them into Mozilla too.
> 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 [EMAIL PROTECTED]
>
Best regards,
-Vlad
; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to [EMAIL PROTECTED]
