Re: LYNX-DEV Lynx Form data Problem

[Foteos Macrides]

address@hidden wrote:
>       Problem with Lynx incorrectly adding form arguments.
>This form data is produced by a script which is called repeatedly with
>different form data (post and get) and with no form data to return to the top
>level selection (as in the 'Return to calendar' link). When the Return link is
>activated previously used form data is sent with it, despite the fact it is not
>the submit link and is outside the <FORM> block.
>
>       A demonstration of the script can be tested at :---
>
>       http://www.marshall.edu/htbin/calendar
>
>...[snip]...
><HR>
><FORM METHOD=POST ACTION="calendar.com"><STRONG>
>[...]                    ^^^^^^^^^^^^^^
></STRONG></FORM>
><P><A HREF="/htbin/calendar.com">Return to the Calendar</A>
>[...]      ^^^^^^^^^^^^^^^^^^^^^

        Though those look different to you in the markup, due to the
document's base they are both being resolved to:

         http://host/htbin/calender.com

and you are up against a limitation of the caching design for forms with
POST content.  The ACTION specifies a family of submission URLs with the
same RequestURI (the http://host/htbin/calender.com).  When the METHOD
is GET, each member of the family is distinguished by the ?name1=value1...
that is appended, so that all submissions are functionally cached and can
be distinquished from each other and the RequestURI.  When the METHOD is
POST, you have a family of the form

        http://host/htbin/calender.com[post_content]

where the post_content is in memory, not URL encoded, and only that for
the last submission is maintained (and assumed for the RequestURI).  You
can make up for that limitation by including PATH_INFO, which will make
the situation more clear for your CGI script as well:

[...]
<FORM METHOD=POST ACTION="/htbin/calendar.com/action"><STRONG>
[...]                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
</STRONG></FORM>
<P><A HREF="/htbin/calendar.com/anchor">Return to the Calendar</A>
[...]      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^

When the CGI script sees PATH_INFO=action, it knows that this was a
form submission, whereas PATH_INFO=anchor makes clear that it is due to
activation of a normal hypertext link, and similarly, Lynx will not
be confused by the RequestURIs.

        You have the equivalent problem with mailto RequestURIs that
have different TITLE attributes:

<A HREF="mailto:address@hidden"; TITLE="Subject One">...</A>
[...]
<A HREF="mailto:address@hidden"; TITLE="Subject Two">...</A>

have the same RequestURI, and the second default subject string will
simply relace the first when rendering the document.  However:

<A HREF="mailto:address@hidden";>...</A>
[...]
<A HREF="mailto:address@hidden";>...</A>

are two different RequestURIs, and will yield different default subject
strings depending on which link was activated.

                                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.
;