His profile
is one of the "broken" ones. I now know the reason, but I'm unclear on how to report it as a bug to the vB team.
The reason (for those of you that care

) is (roughly) down to a bug in the code that sends data to the browser incorrectly.
Some browsers can support simple compression algorithms which cut down on the size of the data transferred considerably. These browsers tell the webserver that they are capable of this and the webserver responds accordingly by compressing the data before it is sent. It is up to each browser to tell the webserver this, though. Users who cannot see ID's (and others) profiles are unable to do so because their browser tells the server that they can accept compressed webpages. The
reason his profile is broken though, is because it seems PHP is reporting an error
after the page is being compressed to be sent (or, more probably vB is using output buffering and automatically compressing the output, flushing the buffer, and
then php is sending the error.)
To see what I mean, look at the following snippet of response from the mud servers when a browser does not specify to compress the page:
Trying 204.10.140.65...
Connected to forum.ih8mud.com.
Escape character is '^]'.
HTTP/1.1 200 OK
Date: Wed, 09 Apr 2008 15:10:17 GMT
Server: Apache/2.2.2 (Fedora)
X-Powered-By: PHP/5.1.6
Cache-Control: private
Pragma: private
X-UA-Compatible: IE=7
Vary: Accept-Encoding,User-Agent
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=ISO-8859-1
eea8
<br /><strong>Warning</strong>: mktime() expects parameter 4 to be long, string given in <strong>[path]/includes/class_userprofile.php</strong> on line <strong>260</strong><br /><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
See that warning? Ok, now look at what you get when you specify
to compress the page:
Trying 204.10.140.65...
Connected to forum.ih8mud.com.
Escape character is '^]'.
HTTP/1.1 200 OK
Date: Wed, 09 Apr 2008 14:57:24 GMT
Server: Apache/2.2.2 (Fedora)
X-Powered-By: PHP/5.1.6
Cache-Control: private
Pragma: private
X-UA-Compatible: IE=7
Content-Encoding: gzip
Content-Length: 16828
Vary: User-Agent
Connection: close
Content-Type: text/html; charset=ISO-8859-1
<br /><strong>Warning</strong>: mktime() expects parameter 4 to be long, string given in <strong>[path]/includes/class_userprofile.php</strong> on line <strong>260</strong><br />‹ }ywG’çßÒ{þixÚ¤z€àMJ¤—¢Ó£Ë"e
Notice that funny looking stuff at the end? Thats binary data, yet the warning still appears before it in plaintext: it shouldn't. That warning should have gotten lumped into the output before it all got compressed, but it managed to get prepended to the already compressed output. This effectively invalidates the entire blob of compressed data (since it is binary, inserting plaintext effectively breaks all of the data that was sent because the browser can no longer decompress the corrupted output)
Still trying to pin down the roots of this problem a little more and figure out the best way to report it to the vB developers.