Re: LYNX-DEV problem getting lynx-cgi to work

[Foteos Macrides]

Al Gilman <address@hidden> wrote:
>  
>Well, the way I read his post, he would _take_ a working cgi script,
>but he would _rather_ just use a mailto: and be done with it.

        Yes, that's what he would like, and I was explaining to him and
you why it is not, and should not be, possible.


>The way you have implemented cc: as a mailto: paramter --
>
>       - can the parameter contain a list of email addresses?
>
>       - can the user edit the cc: list to kill some but not
>       all of the emails provided by the URL?
>
>If he has that, I'm not sure he needs a form.

        You need to think about and understand the difference between
mailto as an HREF in a LINK or Anchor, versus as the ACTION in a
FORM.  In a LINK or Anchor the ?searchpart is a DISadvised field
in the actual URL, which, as a form of "error recovery", the FM code
acts on by:

        (1) Treating any subject= field as an advisory Subject header,
offering it to the user for editing as it would the value of a TITLE
attribute (whose use IS advised instead of the ?searchpart tack-on
kludge).

        (2) The primary address in the mailto URL could be a
comma-separated list (or, as another form of error recovery, a
semi-colon-separated list to accomodate uninformed Webizens using
MSIE with Exchange).  The FM code will treat any cc= fields in the
?searchpart as extensions of the primary address, adding the values
to that primary, comma-separated list.  The cc= values, themselves,
can be single addresses, or comma-separated (or semi-colon-separated)
lists.  The user also is prompted for a Cc: with the user's personal
mail address as the default, and that's what Lynx uses as an actual Cc:
("secondary address").  The primary address or address list, however
derived, cannot be edited.  It must be accepted or rejected as a whole,
just as you must accept or reject the addresses of other URL schemes as
a whole.  Only the supplementary, user-entered secondary address is
optional and modifiable.

        (3) The body= field, if present, is used (instead of offering
the current document with "> " line prefixing) as the message body.
It can be edited if you have an editor defined, otherwise is scrolled
for review and acceptence or rejection by the user.

        (4) Anything else in the ?searchpart is ignored.


        If a mailto URL is used as the value of an ACTION in a FORM,
and it included a ?searchpart tack-on kludge, as a matter of "error
recovery" the FM code will trim it, handle any subject= field in
it as it would a TITLE attribure value, and handle any cc= fields
in it as comma-separated extensions of the primary address field.
It will ignore any body= field, because by definition the body must
be constructed from the FORM content, and mailed to the primary address
(or list) equivalently to a POST.  I also added a Cc: option, with
the personal mail address as the default, so that you can have a
self-copy of the FORM submission.  However, if you want the FORM
to offer a list of addresses from which a subset is selected for
mailing, that must be handled as FORM content, and sent to the ACTION
URL as a body, not appended to the ACTION URL and treated as a component
of it by the client, itself.  You could instead do something like this:

<FORM METHOD=GET ACTION="http://host/script/address@hidden";>
<DL COMPACT>
<DT>Mail to <em>address@hidden</em> and:
<DD><INPUT TYPE=CHECKBOX NAME="cc" VALUE="address@hidden" CHECKED>Foo One
<DD><INPUT TYPE=CHECKBOX NAME="cc" VALUE="address@hidden">Foo Two
<DD><INPUT TYPE=CHECKBOX NAME="cc" VALUE="address@hidden" CHECKED>Foo Three
</DL>
<TEXTAREA NAME=body>
Blah.
</TEXTAREA>
<INPUT TYPE=SUBMIT> <INPUT TYPE=RESET>
</FORM>
 
and have the script return redirection of this sort:

        Location: mailto:address@hidden@host&address@hidden&body=Blah.


        Some people object to the ability to modify the Subject, but I
think that should always be treated as "advisory".  It's debateable
whether the body= field should be modifiable, but I think that should
be "advisory" as well.  It's an issue if you're using the ?searchpart
tack-on kluge for what was intended with the mailserv scheme:

        <A HREF="mailto:address@hidden";
        >Subscribe to the lynx-dev list</A>

It would be a simple hack of the FM LYMail.c to make components of a
primary address list advisory, but IMHO that should be all or none.

                                Fote

=========================================================================
 Foteos Macrides            Worcester Foundation for Biomedical Research
 address@hidden         222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================
;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;