== My mistake with the _Host:_ HTTP header

One of the nice things about writing a blog is getting to say 'oh, oops,
I was a dumbass, let me fix that'. Today I have to own up to a big
example of this.

Back at the start of WanderingThoughts, I wrote [[an entry
HTTPRedirects]] where I complained in part:

> In theory the absolute URL should include the port (unless it's the
> default). In practice, every program I've tried gleefully adds the
> port itself if it is a non-standard port and you're referring to the
> same hostname.

I was a [[moron http://diveintomark.org/archives/2004/08/16/specs]].

The _Host:_ header in HTTP requests includes the port when the port is
a non-standard one (and some programs throw it in even when you're on
port 80, as I found out later). My code looked more or less like:

> _newuri = "http://%s:%d" % (HostHeader, MyPort) + relUrl_

When programs gave me real _Host:_ headers, where _HostHeader_ included
both hostname and port, I effectively doubled the port and things
naturally exploded. Had I printed the actual _Host:_ header that
programs were handing DWiki I would have seen my mistake immediately,
but instead I was too confidant that I knew what was going on and didn't
bother; I trusted my testing with hand-crafted HTTP requests, where I'd
gotten the _Host:_ header wrong and so the result looked right.

I only found all this out months later when I was doing something else
with the _Host:_ header that blew up because I didn't know to expect the
':port' on the end; *that* time I dumped debugging information, partly
because the failure was more mysterious.

My mistake is all the more embarrassing because, contrary
to what I wrote in the [[original entry HTTPRedirects]],
the proper behavior is described in black and white
in the HTTP 1.1 RFC's section on the [[Host header
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.23]].
I am not sure what RFCs I read at the time of the original entry,
but evidently I didn't read the important one.