Re: lynx-dev Location: redirects and reading data

[Klaus Weide]

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.

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 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.

> 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.

> 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.

   Klaus


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