[Top][All Lists]

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

Re: [Lynx-dev] mime_header in Lynx

From: Sigletos George
Subject: Re: [Lynx-dev] mime_header in Lynx
Date: Wed, 18 Jun 2008 11:12:10 +0200
User-agent: Thunderbird (X11/20080501)

Thank you all for your help.

When I use lynx as follows:
"lynx -accept_all_cookies <url>", or "lynx -accept_all_cookies -source <url>"
then I can view the content.

I was expecting that adding the "-mime_header" option,
"lynx -accept_all_cookies -mime_header <url>"
I could also view the header. I use Lynx Version 2.8.6rel.5 on Fedora 8.

Thomas Dickey wrote:
On Tue, Jun 17, 2008 at 04:46:11PM +0200, Sigletos George wrote:
Good afternoon,
The "mime_header" option in lynx is supposed to print the MIME header along with the source of a document.

Why is this not working using -for example- the following link?

What is printed is:
HTTP/1.1 302 Found
Connection: close

with 2.8.5rel.1 and 2.8.7dev.9, I get more than that:

    HTTP/1.1 302 Found
    Connection: close
    Date: Tue, 17 Jun 2008 21:44:32 GMT
    Server: Microsoft-IIS/6.0
    X-AspNet-Version: 2.0.50727
    Set-Cookie: CB%5FSID=7388f33b063446a1aab42750b2d29d79-267039873-wr-6;; path=/
BID=X1C0848E0041471C69DCC781DE8FD725E029DD78B7CC45A36A0CE6BDF433D95439DC9AF9941581966B13BBED57B89D60EB;; expires=Wed, 17-Jun-2009 21:44:32 GMT; path=/
    Set-Cookie: RDB=;; path=/
    Cache-Control: private
    Content-Length: 0


    The requested resource resides temporarily under a different URI.  Since
    the redirection might be altered on occasion, the client SHOULD continue to
    use the Request-URI for future requests.  This response is only cacheable
if indicated by a Cache-Control or Expires header field. The temporary URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s).
    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.
          Note: RFC 1945 and RFC 2068 specify that the client is not allowed
          to change the method on the redirected request.  However, most
          existing user agent implementations treat 302 as if it were a 303
          response, performing a GET on the Location field-value regardless
          of the original request method. The status codes 303 and 307 have
          been added for servers that wish to make unambiguously clear which
          kind of reaction is expected of the client.

With the -trace option, I don't see any additional content:

    Accept: text/html, text/plain, text/css, text/sgml, */*;q=0.01\r
    Accept-Language: en\r
    User-Agent: Lynx/2.8.7dev.4 libwww-FM/2.14 SSL-MM/1.4.1 OpenSSL/0.9.8c\r
    Sending HTTP request.
    HTTP: WRITE delivered OK
    HTTP request sent; waiting for response.
    HTTP: Trying to read 1535
    HTTP: Read 754
HTTP: Rx: HTTP/1.1 302 Found HTTP: Scanned 2 fields from line_buffer
    --- Talking HTTP1.
    HTTP/1.1 302 Found
    HTFormat: Constructing stream stack for text/plain to www/dump ((null))
    HTFormat: Looking up presentation for text/plain to www/dump
    HTFormat: comparing image/* and text/plain for half match
    StreamStack: found weak wildcard match: www/dump
    StreamStack: Using www/dump
    StreamStack: Returning "FileWriter"
    Data transfer complete

reply via email to

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