#115426 Intepretation of missing content-type field (Doesn't work with http://www.netflix.com)

Package:
links
Source:
links2
Description:
Web browser running in text mode
Submitter:
Date:
2005-07-18 03:22:35 UTC
Severity:
wishlist
#115426#5
Date:
2001-10-13 01:44:33 UTC
From:
To:
As stated in the subject, links doesn't work with netflix, although lynx,
netscape, galeon, mozilla, etc work, so it's not a generic "dumb website
testing for client type" problem.
--- Begin /etc/links.cfg (modified conffile)
async_dns 1
download_utime 0
max_connections 10
max_connections_to_host 2
retries 3
receive_timeout 120
unrestartable_receive_timeout 600
format_cache_size 5
memory_cache_size 1M
http_proxy ""
ftp_proxy ""
download_dir ""
language "English"
http_bugs.http10 0
http_bugs.allow_blacklist 1
http_bugs.bug_302_redirect 0
http_bugs.bug_post_no_keepalive 0
ftp.anonymous_password "links-user@debian.org"
terminal "linux" 2 1 5 ISO-8859-1
association "GIF image" "image/gif" "see %" 23 1
mailto "mutt %" 1
telnet "telnet %" 1
tn3270 "telnet %" 1

--- End /etc/links.cfg
#115426#10
Date:
2001-10-15 08:05:32 UTC
From:
To:
severity #115426 wishlist
retitle #115426 Intepretation of missing content-type field (Doesn't work with http://www.netflix.com)
tags +wontfix
thanks

This is not a bug in links, the webserver at netflix is a piece of excretum
at best (equals "generic dumb website").

HTTP transaction log:
~~~~~~~~~~~~~~~~~~~~~
HTTP/1.1 302 Moved Temporarily
Location: http://www104/Default
Server: WebLogic 5.1.0 Service Pack 9 04/06/2001 12:48:33 #105983 - 128 bit domestic version
Content-Length: 211
Connection: Close

<html><head><title>302 Moved Temporarily</title></head>
<body bgcolor="#FFFFFF">
<p>This document you requested has moved temporarily.</p>
<p>It's now at <a href="/Default">/Default</a>.</p>
</body></html>

As you can see, the server does not privide "Content-Type" field, which
is required if you want it interpreted as text/html. As per RFC2616:

==============================//============================
7.2.1 Type

[...]
   Any HTTP/1.1 message containing an entity-body SHOULD include a
   Content-Type header field defining the media type of that body. If
   and only if the media type is not given by a Content-Type field, the
   recipient MAY attempt to guess the media type via inspection of its
   content and/or the name extension(s) of the URI used to identify the
!  resource. If the media type remains unknown, the recipient SHOULD
!  treat it as type "application/octet-stream".
==============================\\============================

As you can see, it should be included (read: it is advised not to leave it
off). If someone thinks they don't feel like using it, the browser shall
intepret it as application/octet-stream, as links does. If other browsers do
it the other way, they try to guess the content-type based on file name,
content or whatever they feel like.

This is a wishlist I believe will be quite hard to push upstream, because
the author tends not to implement "dirty hacks".

Peter