[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: lynx-dev dev.16 patch 5 corrected
From: |
Klaus Weide |
Subject: |
Re: lynx-dev dev.16 patch 5 corrected |
Date: |
Sat, 11 Dec 1999 14:41:02 -0600 (CST) |
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