[Top][All Lists]

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

Re: lynx-dev Anyone able to access these days

From: Klaus Weide
Subject: Re: lynx-dev Anyone able to access these days
Date: Tue, 15 Aug 2000 00:56:41 -0500 (CDT)

On Sat, 12 Aug 2000, Doug Kaufman wrote:
> On Sat, 12 Aug 2000, Kim DeVaughn wrote:
> > It seems that has been slowly getting less and less
> > "lynx-friendly" over the past ~6-8 months, or so.
> > 
> > Now, however, I cannot even get to their initial page.  I just get
> > the following:
> > 
> >  Looking up
> >  Making HTTP connection to
> >  Sending HTTP request.
> >  HTTP request sent; waiting for response.
> >  HTTP/1.1 302 Redirected
> >  Data transfer complete
> > 
> >  lynx: Start file could not be found or is not text/html or text/plain
> >        Exiting...
> I am a little confused by what is going on. I get the same message using
> 2.8.3dev.18. 

Sometimes -trace is the only way to figure out what the server is telling
the client.

> But a lynx -head shows:

That's not completely reliable since the server might send something
different in response to the HEAD request than what it sends in response
to a GET request.  (And the reason for the difference might not even be
the different request method - HEAD vs. GET - but something else like
presence/absence of a Referer header.)

> HTTP/1.1 302 Redirected
> Server: Microsoft-IIS/5.0
> Date: Sat, 12 Aug 2000 16:49:46 GMT
> Location:
> Going manually to that address requests two cookies, but you get
> the login screen regardless of whether cookies are accepted or
> not. Is the problem that on redirect the file is not text/html
> or text/plain? 

Which file?

The HTTP protocol deals with messages (not files).  Is there any
message that should carry a Content-type header but doesn't?  I doubt
it.   The redirection response message itself is normally not displayed
by lynx (unless you use -noredir), so its MIME type doesn't matter.

> Looking at the trace file, it appears to be
> "message/x-http-redirection". 

That is only an internal designation for "handle this as a redirection
message", it is not something received from outside.

The handling of redirection messages has changed:
   1999-12-15 (2.8.3dev.17)
   * changed how HTTP redirection messages are handled.
see CHANGES for full desacription.

> Trying "lynx -force_html" doesn't work
> to fix this. 

The -force_html option is irrelevant for protocols that carry Content-type
information in the protocol, i.e. HTTP.  (as someone else pointed out.)

> Does that only work on the first URL, before redirection
> takes place?

It turns out that the redirection message itsaelf, as sent from, is defective.  It consists only of HTTP headers but no
body.  Not just an empty body, but NO body:  the empty line (CR LF 
CR LF) that should separate headers from body (even if the body is empty)
is missing, therefore the message itself is malformed.

This analysis is based on what I can capture into a file using
  no_proxy='*' src/lynx -mime_header > /tmp/somefile
Compare to some other server's redirection messages.
If I use a squid proxy, squid goes into a loop for several attempts and
ultimately complains about 
   The following error was encountered:
     * Zero Sized Reply
which shows that it isn't lynx alone that has a problem.

Lynx BEFORE the changes of 2.8.3dev.17 does recognize the broken
redirection and follows it (or rather, it doesn't notice that the
message is broken); lynx since 2.8.3dev.17 doesn't follow the redirection
since it is waiting for an empty line to terminate the HTTP header fields
which never comes.  I believe the latter behavior is more correct.


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

reply via email to

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