[Top][All Lists]

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

Re: [Lynx-dev] mime_header in Lynx

From: Thomas Dickey
Subject: Re: [Lynx-dev] mime_header in Lynx
Date: Tue, 17 Jun 2008 17:52:09 -0400
User-agent: Mutt/1.5.17+20080114 (2008-01-14)

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

Thomas E. Dickey <address@hidden>

reply via email to

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