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

[Klaus Weide]

On Sat, 15 Jul 2000, Joris Dobbelsteen wrote:

> You got some discussion about sending FORMS (with "mailto:*"; URLs). It
> seemed that you got no question before sending this you got no conformation
> that you were sending data to anyone via e-mail, but isn't it better if you
> warn the user before sending ANY data.

Sure it's better.  There is at least a

 Subject: [some prefilled text]

prompt that appears in that case.  (Leonid didn't see it, but that's
because he messed with the source as I understand it.)  So the user
_should_ notice that lynx is about to send mail by the appearance
of that prompt, even if he/she missed an earlier statusline indication
that the link is a "mailto form submit button" (or something similar).
The user can cancel with ^G at that point.

The questions i raised were
 - Is this clear enough?  An unsophisticated user might not understand
   that "Subject:" means that a mail is to be sent, and just press enter.
   (But normally, there will be yet another "Cc:" prompt before lynx
   really tries to send the message.
 - The user cannot see what exactly will be sent, and to whom.

> You can let the user choose ALWAYS
> WARN, DON'T WARN AGAIN ON THIS SITE/PAGE, NEVER WARN, .......... regardless
> of the destination you are sending to.....

As with all such nice ideas, someone has to write the code...
In the case of the rarely used[*] mailto form action, I doubt it
is important enough for _that_ level of configurability.

[*] Because it doesn't work reliable even on "mainstream" browsers.

> Maybe an idea to review the transmission of the FROM, REFERER and USER-AGENT
> header, if they are supported (and used). the USER-AGENT header can be
> changed, so that's good already...

Sending of "From" and "Referer" headers in HTTP requests can also
already be configured, see lynx.cfg and 'lynx -help'.  Sending of
"From" is off by default.

> Before I forget to mention, on this mailing list there are sometimes
> discussion about user preferences, someone loves (silly) questions, the
> other one doesn't want them, why not make them configurable, since only
> compile-time configurable settings will cause (most of the times), in this
> case, a big discussion on this mailing list (and that causes all the
> bandwidth of my modem to be 'used' when I'm checking for new mail).

If someone is interested enough in making behavior XY configurable,
and can provide the patches, it normally will get included.  If not -
natural selection...

   Klaus


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