tclhttpd.3.5.1 shows page source (Windows) - http-headers

Question

I am playing with tclhttpd web server and found a strange error
I start tclhttpd at default port 8015
Open firefox and navigate to http://localhost:8015
I see source of my index.html file instead of web page.
index.html is simple ( < and > are skipped ):
html
head
title
TEST
/title
/head
body
H1 TEST HEADER /H1
/body
/html
Any ideas?
I have checked with the curl:
* About to connect() to localhost port 8015 (#0)
* Trying 127.0.0.1... connected
* Connected to localhost (127.0.0.1) port 8015 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.21.3 (i386-pc-win32) libcurl/7.21.3
OpenSSL/0.9.8q zlib/1.2.5
> Host: localhost:8015
> Accept: */*
Server Response
HTTP/1.1 200 Data follows
Date: Thu, 12 Apr 2012 14:16:47 GMT
Server: Tcl-Webserver/3.5.1 May 27, 2004
Content-Type: text/plain
Content-Length: 130
Last-Modified: Thu, 12 Apr 2012 14:14:30 GMT
So, tclhttpd returns text/plain instead of text/html
Linux case
I have tried to check what would happened with Linux.
As tclkttpd is wrapped in kit I made the same test under Linux.
It looks like everything works fine.
curl -G -v localhost:8015
* About to connect() to localhost port 8015 (#0)
* Trying 127.0.0.1... connected
* Connected to localhost (127.0.0.1) port 8015 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.21.7 (i686-pc-linux-gnu) libcurl/7.21.7
OpenSSL/1.0.0d zlib/1.2.5 libssh2/1.2.7
> Host: localhost:8015
> Accept: */*
Server response
HTTP/1.1 200 Data follows
Date: Thu, 12 Apr 2012 17:25:29 GMT
Server: Tcl-Webserver/3.5.1 May 27, 2004
Content-Type: text/html
Content-Length: 125
Last-Modified: Thu, 12 Apr 2012 17:14:04 GMT
Deep research
I have modified some of the source files, to dump more information:
proc Mtype {path} {
global MimeType
set ext [string tolower [file extension $path]]
Stderr "Mtype: path $path ext $ext"
if {[info exist MimeType($ext)]} {
Stderr "MimeType($ext) exists."
Stderr "Print MimeType "
set lst [lsort [array names MimeType]]
foreach {i} $lst {
Stderr " $i $MimeType($i)"
}
return $MimeType($ext)
} else {
Stderr "Mimetype not found. ext $ext"
Stderr "Print MimeType "
set lst [lsort [array names MimeType]]
foreach {i} $lst {
Stderr " $i $MimeType($i)"
}
return text/plain
}
}
When I query http://localhost:8015
I got following output:
Linux
Mtype: path /home/a2/src/tcl/tcl_www/doc/index.html ext .html
MimeType(.html) exists.
Print MimeType
text/plain
.ai application/postscript
.aif audio/x-aiff
.aifc audio/x-aiff
....
.hqx application/mac-binhex40
.htm text/html
.html text/html
.i86pc application/octet-stream
...
Default cmd Doc_text/html
Windows
Look for Tcl proc whos name match the MIME Content-Type
Mtype: path M:/apr/tcl_www/doc/index.html ext .html
Mimetype not found. ext .html
Print MimeType
.man application/x-doctool
Mtype M:/apr/tcl_www/doc/index.html returns Doc_text/plain
So it look like there are troubles with reading mime.types

Answer 1

You have to inspect the traffic tclhttpd generates to see if it really says in the HTTP headers of its response that the payload type is "text/html".
Use Fiddler, sockspy, Microsoft Network Monitor or Wireshark.
Also there are lighter-weight debugging tools for browsers. I'm pretty sure Firebug wold show you this information, and even simple Live HTTP Headers can do that.
IE also has some debugging addon (akin to Firebug) which I'm lazy to google for.

Answer 2

Problem found.
httpdthread.tcl
# Core modules
package require httpd ;# Protocol stack
package require httpd::version ;# Version number
package require httpd::url ;# URL dispatching
package require httpd::mtype ;# Mime types
# Search for mime.types either right in Config(lib), or down
# one level in the installed tclhttpd subdirectory
foreach path [list \
[file join $Config(lib) mime.types] \
[glob -nocomplain [file join $Config(lib) tclhttpd* mime.types]] \
] {
if {[llength $path] > 0} {
set path [lindex $path 0]
}
if {[file exists $path]} {
Mtype_ReadTypes $path
break
}
}
This code checks for the mime.types file under following paths:
- /home/a2/..../tclhttpd3.5.1.kit/bin/../lib
- /home/a2/..../tclhttpd3.5.1.kit/bin/../lib/tclhttpd*/mime.types
Linux
glob -nocomplain /home/..../tclhttpd3.5.1.kit/bin/../lib/tclhttpd*/mime.types]
works fine and returns
/home/....tclhttpd3.5.1.kit/bin/../lib/tclhttpd3.5.1/mime.types
Windows
glob -nocomplain /home/..../tclhttpd3.5.1.kit/bin/../lib/tclhttpd*/mime.types]
failed.
I have tried different masks:
tclhttpd*
tclhttpd*.*
tclhttpd*..
nothing is working
Finally I have modified the code:
foreach path [list \
[file join $Config(lib) mime.types] \
[glob -nocomplain [file join $Config(lib) tclhttpd* mime.types]] \
[file join $Config(lib) [lindex [Httpd_Version] 0] mime.types]
] {
if {[llength $path] > 0} {
set path [lindex $path 0]
}
if {[file exists $path]} {
Mtype_ReadTypes $path
break
}
}
string
[file join $Config(lib) [lindex [Httpd_Version] 0] mime.types]
generate the path:
/home/..../tclhttpd3.5.1.kit/bin/../lib/tclhttpd3.5.1/mime.types
Now tclhttpd could find mime.types under windows.
And it looks like that problem happened only if glob is searching inside the statkit file.

Answer 3

I have checked with the fresh tclkitsh and tclhttpd
tclkitsh-8.5.9-win32.upx.exe ( http://code.google.com/p/tclkit/downloads/list )
tclhttpd5.3.1.kit
Everything works.
If I use my "old" version of tclkitsh-win32.upx.exe
I receive text/plain instead of text/html
So it looks like there is a bug in my old wrapped interpretor, that leads to the problem with not reading mime.types.

Answer 4

I think tclhttpd automatically uses text/html if the file ends with .html. You properly should read this wiki entry on wiki.tcl.tk about mime-type.
Tried it myself with a index.html and it worked. Than I created an index.tml and it worked.
[html::description "Test"]
[Doc_Dynamic]
[html::head "hello"]
<body>
test
</body>
</html>
Here is the header part of the response:
HTTP/1.1 200 Data follows
Content-Length: 137
Date: Thu, 12 Apr 2012 16:47:53 GMT
Server: Tcl-Webserver/3.5.1 May 27, 2004
Connection: Close
Content-Type: text/html

Answer 5

The reason for curl getting text/plain instead of text/html might be that it passes */* in the Accept header of its HTTP requests, while typically browsers place some more elaborate construct there—for instance, my FF 11.0 uses text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8.
One might notice that in the FF's case text/html (along with XHTML and XML types) is assigned a higher preference (0.9) and everything else (*/*) is assigned a lower preference (0.8).
A conformant HTTP server should attempt to serve the requested resource in a format indicated as preferred in the client's request.
Probably that might also shed some light on that original IE vs FF behavioral difference.