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?
http://www.jobbingmall.nl/INTL/JobSeeker/Jobs/JobDetails.aspx?IPath=JRTCM&sc_cmp1=JS_JR_ViewJob&APath=2.21.0.0.0&job_did=J3I3K96MVN1YPSZGZJ9
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-PBY:REBEL1
X-AspNet-Version: 2.0.50727
Location:
http://www.jobbingmall.nl/INTL/JobSeeker/Jobs/JobDetails.aspx?IPath=JRTCM&sc_cmp1=JS_JR_ViewJob&APath=2.21.0.0.0&job_did=J3I3K96MVN1YPSZGZJ9&cbRecursionCnt=1&cbsid=7388f33b063446a1aab42750b2d29d79-267039873-wr-6
Set-Cookie: CB%5FSID=7388f33b063446a1aab42750b2d29d79-267039873-wr-6;
domain=.jobbingmall.nl; path=/
Set-Cookie:
BID=X1C0848E0041471C69DCC781DE8FD725E029DD78B7CC45A36A0CE6BDF433D95439DC9AF9941581966B13BBED57B89D60EB;
domain=.jobbingmall.nl; expires=Wed, 17-Jun-2009 21:44:32 GMT; path=/
Set-Cookie: RDB=; domain=.jobbingmall.nl; path=/
Cache-Control: private
Content-Length: 0
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
says
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:
GET
/INTL/JobSeeker/Jobs/JobDetails.aspx?IPath=JRTCM&sc_cmp1=JS_JR_ViewJob&APath=2.21.0.0.0&job_did=J3I3K96MVN1YPSZGZJ9
HTTP/1.0\r
Host: www.jobbingmall.nl\r
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
\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