lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

lynx-dev Referer, URL with fragment, redirection limit


From: Serge MUNHOVEN
Subject: lynx-dev Referer, URL with fragment, redirection limit
Date: Sat, 3 Oct 1998 06:21:07 +0200

Dear all

Here some collected and totally unrelated problems encountered with lynx
(up to 2.8.1pre6) :

1) referer header:
On Thu, Sep 24, 1998 at 06:37:10PM +0100, Bruno Prior wrote:
 >  
 >  What I don't understand is why version 2.8 would take the retrograde step of
 >  introducing an incompatibility that did not exist in earlier versions of the
 >  browser. This is not the only example. It appears from another script of
 >  mine that lynx 2.8 does not send the HTTP_REFERER environment variable by
 >  default, whereas lynx 2.6 does. I would hope that there is some way to
 >  enable sending of this variable from version 2.8 browsers, but I can't find
 >  it. Does anyone know how?
 >  
I had a similar problem which was quite tricky to hunt down, because in most
cases lynx *does* send an HTTP_REFERER header. From memory (I may be wrong on
some details), it does not automatically so if the referer is a local file
(depending on the configuration; hiding the local filesystem structure), or a
bookmark. It never does so if the referer is the reply to a previously
submitted form, according to a comment in the source, for quite understandable
security reasons (hiding eventually sensitive data). It neither does if the
user edited the target link, nor for "transient" links (e.g. history entries).

Since, in my case, navigation through a frequently used site depended on
HTTP_REFERER being send rather than a hidden form-variable (br..ight idea),
I've been running a patched 2.8.1dev19 sending this header, but
droping trailing form-data and removing the hostname and directory part for
file-referers. Shouldn't this be enough to meet the mentionned security
concerns ? Actually I thought being the only one with that problem ...
My patch seems to apply to 2.8.1pre6 as well. If there is interest, I'll have
a closer look at it on Monday and submit it.

BTW: Any comments on what the standard says about those HTTP_REFERER headers ?


2) URL with fragment identifier
When following a link like "file#fragment", with the rendered "file" holding
on one screen, the "cursor" is set to the first link in file, rather than
to "fragment". First time this happened to me, I thought that my HTML was bad.
So I tried to debug it, but accessed exactly the same file on a smaller screen,
and lynx correctly moved to "fragment". The bug became sporadic, driving me
nuts, until I noticed that the changing parameter was my screen size ...
Unfortunately I did not have time to investigate how this is handled by lynx.

3) redirection limit with no-cache submit
Accessing e.g. http://www.lights.com/publisher and submitting the form 
(accepting the proposed cookie, since it is mandatory ...) the redirection
limit is hit and we don't move. Forcing submission of the form with no-cache
(x), the same happens, *but* the current document is reloaded and form entries
are lost. When just now checking this with 2.8.1pre6, I once did manage to get
a valid reply, but don't see how ... Seems to me the cookie is playing a role.
But after emptying the cookie-jar to restart from scratch (without quiting
lynx), I'm not even asked anymore to accept a new one ?!
I'll perhaps again have a look at it after getting some sleep.

Regards,

 Serge

-- 
-                                                                             -
 Serge Munhoven                              Internet: address@hidden
 Universite Catholique de Louvain               Phone (office): ++32-10-478032
 CESAME - Applied Mechanics Division                (division): ++32-10-472350
 Av. Georges Lemaitre, 4                                   Fax: ++32-10-472180
 B-1348 Louvain-la-Neuve (Belgium - Europe)                      Office: a.011
-                                                                             -

reply via email to

[Prev in Thread] Current Thread [Next in Thread]