Bug#44811: search_packages.pl creates bogus links

[Klaus Weide <kweide@enteract.com>]

Package: www.debian.org
Version: N/A

Apparently the script invoked by (for example)

  <http://cgi.debian.org/cgi-bin/search_packages.pl?keywords=lynx&;
   searchon=names&version=all&release=all>

uses the Referer HTTP header, if it is being sent, to construct
the links in the returned page.  I assume this is meant to point
the reader back at the right Web page mirror, like www.us.debian.org,
www.de.debian.org, etc.  But Referer-based navigation is fundamentally
unreliable.

For demonstration, I created a local file ~/lynx_bookmarks-copy.html,
(I) with a link to the above URL.  Following this link using lynx [*]
results in what looks at first like the usual Search Results page, but
with all the links wrong.  For example, what should have been a link to

  <http://www.debian.org/Packages/stable/web/lynx.html>

is instead a link to

  <file://localhost/home/kweide/lynx_bookmarks-copy.html/Packages/stable/
   web/lynx.html>.

(II) By using a link to <http://packages.debian.org/lynx/> instead,
which redirects to the long URL above, I get the same result as above.

(III) In some situations lynx can send a completely unreleted Referer,
when returning with Left Arrow to a document that has dropped out of
its cache of rendered documents.


Relying on Referer for correct links is a Bad Idea in general.
You should at least check the header value for plausibility.
It probably should match "http://*.debian.org/* or something like
that.  If the string doesn't look right, do the same thing you do
when Referer is absent.

Or you could somehow pass through the hostname as part of
the URL query string, at least in some situations.


[*] III can be argued to be misbehavior on lynx's part.  I believe it
is acting correctly for I and II.
Note I had to put the links into a file not recognized as a bookmark
file, and make sure the -nofilereferer option (or its lynx.cfg
equivalent) is not set, for lynx to send Referer.  This is not material
to the point, no such steps would be necessary to demonstrate the
problem if I chose to access the file via an http (or ftp,...) URL.

   Klaus