lynx-dev
[Top][All Lists]
Advanced

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

Re: lynx-dev Location: redirects and reading data


From: brian j pardy
Subject: Re: lynx-dev Location: redirects and reading data
Date: Sun, 28 May 2000 18:08:06 -0400

On Sun, May 28, 2000, Klaus Weide wrote:
> On Sat, 27 May 2000, brian j pardy wrote:
> 
> > Try going to http://www.freshmeat.net/ with trace on, preferably on a
> > slow connection.
> 
> Yes.  I also already had noticed this, with the same URL.
> (And I am on a slow connection.)
> 
> > The server responds with a 302 and gives a Location: header pointing
> > to http://freshmeat.net/ -- all well and good, but the server also
> > sends the entire ~70k index page that is actually on
> > http://freshmeat.net/.
> 
> It's broken.  Complaints should go to Freshmeat.
> 
> > As Lynx never displays this data, I wonder if it is even worth
> > maintaining the server connection.  
> 
> This is the only site I'm aware of that sends such an insane
> redirection message.  It isn't worth changing the code for just
> that site IMO.

Okay, I was basically wondering if this was something anyone had been
seeing on other sites, or if this was just a single insane server.

> Note that there have been changes in the way redirection messages
> are parsed, since Lynx 2.8.2.  You should be able to observe some
> differences if you try the same thing with an older version.
> 
> The basic thing you are complaining about hasn't changed, though:
> Lynx reads from the connection until it gets an EOF indication.
> That's generally the right thing to to, whether we actually want
> the body contents of the message or not.  It's friendlier to servers
> (no "client has reset connection" or similar messages in their logs)
> and is generally how TCP connections should be handled IMO.

I did think of that -- and it could be something to give sites another
reason to ban Lynx.

> > I took a quick look over the spec,
> > and the only reason I would see that we shouldn't automatically
> > redirect to the next page is the following:
> > 
> > 10.3.3 302 Moved Temporarily
> > 
> >    [...]
> > 
> >    If the 302 status code is received in response to a request other
> >    than GET or HEAD, the user agent MUST NOT automatically redirect the
> >    request unless it can be confirmed by the user, since this might
> >    change the conditions under which the request was issued.
> 
> That's irrelevant - it's about other HTTP methods like POST.

Yup.  I was just saying that was the only thing I could find with any
tentative relation to what I was talking about.  

> > I'm not sure if we are required to load this data -- however, if we are,
> > we're definitely not doing anything with it.
> 
> The server is sending a response message, and we are reading it.  Non-
> broken sites don't put tens of unnecessary kBytes in messages.

Agree.

> > Does anybody have any reason we shouldn't close the connection after
> > we've received all of the server's headers and there is a Location:
> > redirect and we're using a GET or HEAD?  (Other than it being rude, of
> > course.)
> 
> There isn't any noticable advantage except with this broken site, afaik.
> Normally redirection messages have a body but it's very short (should
> fit in one network datagram together with the response headers).
> 
> Even if we closed the connection for this broken case - the TCP/IP stack
> would then send RST packets to the server in response to further incoming
> packets, but the incoming side of the network connection will still
> continue receiving packets until the server has reacted to the first RST
> and all packets that are already underwway have drained from the network.
> So the following request (to the redirected URL) will probably be slowed
> down anyway.

Makes sense to me.

-- 
One of the large consolations for experiencing anything
unpleasant is the knowledge that one can communicate it.
                -- Joyce Carol Oates

; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden

reply via email to

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