Tcl Source Code

View Ticket
Login
Ticket UUID: 504508
Title: port 80 in "Host:" request header
Type: Bug Version: obsolete: 8.3.4
Submitter: apulsifer Created on: 2002-01-16 18:15:10
Subsystem: 29. http Package Assigned To: hobbs
Priority: 5 Medium Severity:
Status: Closed Last Modified: 2002-08-25 09:17:11
Resolution: Fixed Closed By: hobbs
    Closed on: 2002-01-25 03:01:08
Description:
http.tcl v2.4 generates a header line in the http 
request that reads:

Host: www.domain.com:80

I have discovered a server (sorry, can't say where) 
that tries to 302 redirect you to "www.domain.com" 
when you request a document from "www.domain.com:80".  
Yeh, I know its stupid, but since I have no control 
over the server, the only reasonable work around is to 
patch http.tcl.

When patched as follows, it works great:

old code:
puts $s "Host: $host:$port"

new code:
if {$port == 80} {
puts $s "Host: $host"
} else {
puts $s "Host: $host:$port"
}

I suggest making this change to http.tcl in order to 
make it more tolerant of brain damaged servers.

Thanks.
User Comments: cleverly added on 2002-08-25 09:17:11:
Logged In: YES 
user_id=22080

Just for the record, PowerDNS that does the redirection for
wiki.tcl.tk is also brain-dead/broken with regards to:
"Host: wiki.tcl.tk:80" :-(

hobbs added on 2002-01-25 10:01:09:

File Added - 16729: http-port80.txt

hobbs added on 2002-01-25 10:01:08:
Logged In: YES 
user_id=72656

Found a server that reliably exhibits this bug:

http://www.weather.com/weather/local/24060

From the geturl headers, the server is
   Apache/1.3.12 (Unix) mod_oas/5.1/

This obviously violates the RFC:

http://www.w3.org/Protocols/rfc2616/rfc2616-
sec14.html#sec14.23

Anyway, I'm back-porting to core-8-3-1-branch in case that 
ever goes out as well.  I'm also removing the "http" only 
restriction, because now that I see this happen, I can't 
rely on broken servers to hopefully server https right 
either.  I've attached the 8.4a4cvs patch.

hobbs added on 2002-01-25 08:31:53:
Logged In: YES 
user_id=72656

ok, went with the last solution to that restricts it to 
http proto, to stay on the safe side.  This is in 8.4a4cvs.

apulsifer added on 2002-01-25 07:39:04:
Logged In: YES 
user_id=429383

I think it would solve 99% of the problems if you changed 
it to:

if {$port == 80 && "protocol" == "http"} {
puts $s "Host: $host"
} else {
puts $s "Host: $host:$port"
}

Note I downgraded to v8.3.2 and it doesn't have this 
problem.

Thanks,

Allen

hobbs added on 2002-01-25 05:38:56:
Logged In: YES 
user_id=72656

I'd still note this as a server bug, because this might not 
be a robust patch in Tcl.  https and other support 
protocols might prevent the above from behaving properly.

apulsifer added on 2002-01-17 02:38:41:
Logged In: YES 
user_id=429383

I agree, its not a very robust server.  Since the port 
value in the header is optional, this patch would make the 
http package more tolerate of bad server code.

BTW, after looking at the RFC, I realize the patch should 
read (in pseudocode):

if {$port == [default port for the selected protocol]} {

apulsifer added on 2002-01-17 01:47:53:
Logged In: YES 
user_id=429383

I agree, its not a very robust server.  Since the port 
value in the header is optional, this patch would make the 
http package more tolerate of bad server code.

BTW, after looking at the RFC, I realize the patch should 
read (in pseudocode):

if {$port == [default port for the selected protocol]} {

hobbs added on 2002-01-17 01:23:52:
Logged In: YES 
user_id=72656

Can you say what the server was?  That seems inane, since 
the host:port specification is 100% correct with the RFC.  
I'd register this as a bug against the server, rather than 
Tcl.

Attachments: