Re: lynx-dev dev.16 patch 5 corrected

[Klaus Weide]

On Sat, 11 Dec 1999, Henry Nelson wrote:

> > +  --enable-internal-links  (prevent defining DONT_TRACK_INTERNAL_LINKS)
> > +   With this option, `internal links' (links within a document to a
> > +   location within the same document) get treated differently.  Lynx
>                                                                   ^
> "from what" is not explicit.

Implied was: from how they get treated without this option.  But saying that
explicitly doesn't make much sense, so I agree your formulation is better.

> > +   can distinguish between `<A HREF="foo#frag">' and `<A HREF="#frag">',
> > +   for example, within a document whose URL is `foo', and may handle
> > +   them differently.  Practical differences appear only when the
> > +   containing document is the result of a POST request or has a no-cache
> > +   flag set.  According to the author of this feature, it does The Right
> > +   Thing, interprets URL-references as required by RFC 2396, and prevents
> > +   inappropriate resubmissions of form content with the POST method.
> > +   According to a previous lynx maintainer, it does the wrong thing,
> > +   is unnecessary, and can cause inappropriate resubmission of form
> > +   content.
> 
> As you may recall from my fairly recent complaint of a failed compile, I use
> "--enable-internal-links," and actually have been using your code since it's
> inception.

I didn't remember that, sorry.

> On the other hand, I never reveal sensitive information over the
> Internet, SSL or not, especially with POST.  Just so you know my bias.  I also
> confess, although you may already know that, that I am the one who insisted
> on Fote's analysis being the default -- solely on the basis of, however 
> remote,
> "better safe than sorry."

Just to make my standpoint clear, not to start an argument: "better
safe than sorry" could cut both ways, depending on who was right on
the technical points, and in my opinion is an argument for making
--enable-internal-links the default.  But I will leave it at that and
not submit patches to change the default, etc., and just point to
--enable-internal-links in the rare case where it seems to help someone.
(last time this happened: see thread "CGI POST parameters bugs"
in the archive for July 1999)

> While your version is far superior to what is there now, I think it is too
> long, is ambiguous in one respect, and recalls the "personality conflicts"
> which spilled so much emotion into this difference of opinions and ended up
> clouding the issue.

If my text looked a bit like we[*] can't figure out the right decision and
therefore dump the problem on the user (installer) - that was intentional,
since it reflects what is the case IMO.

[*] "lynx-dev" or "Lynx Developers" as a whole - biased parties probably
    excluded

> Would you consider something like the following (as always, a suggestion):
> 
>   --enable-internal-links     (prevent defining DONT_TRACK_INTERNAL_LINKS)
>         With `internal links' (links within a document to a location within
>         the same document) enabled, Lynx will distinguish between, for 
> example,
>         `<A HREF="foo#frag">' and `<A HREF="#frag">' within a document whose
>         URL is `foo'.  It may handle such links differently, although 
> practical
>         differences would appear only if the document containing them resulted
>         from a POST request or had a no-cache flag set.  This feature attempts
>         to interpret URL-references as suggested by RFC 2396, and to prevent
>         mistaken resubmissions of form content with the POST method.  An
>         alternate opinion predicts that the feature could actually result in
>         inappropriate resubmission of form content.

I think it is *much* better expressed, thank you.

A nit: should "predicts" be "has predicted"?  I don't really care though.

   ----

By the way, here is an example I just came across that demonstrates what can
happen when POST data is inappropriately resubmitted: A duplicate problem report
in the apache bug database, which got the response
      Dupe of 5246.  Please only hit submit _ONCE_.
(<http://bugs.apache.org/index/full/5247>)

Was it the user's fault, or maybe the software's fault?  The respondent
can't really know, and so assumes the first.

   Klaus