Oh, that's great. Bad news for those of us who like reliable, predictable
software. What URLs did you get this info from?
You know what though? I wasn't thinking or I'd have realized that that
can't be Daniel's problem. If he's getting TCL code in the browser, then
AOLserver never parsed the code and even tried to execute it. The code
should have never made it to the browser. He and I must have both fallen
into a server config pitfall, at least in the Win32 distribution.
--
Mark Hubbard: [EMAIL PROTECTED]
Microsoft Certified Professional
"Never apply a Star Trek solution to a Babylon 5 problem."
-----Original Message-----
From: Jim Wilcoxson <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Monday, September 17, 2001 10:30 AM
Subject: IE and MIME types
>IE looks at the data that is sent back and will change (for example) the
>MIME type from text/plain to text/html if you send a HTML document with
>the text/plain MIME type. Very stupid of them in my opinion, but what
>do I know. It doesn't just look at the extension when deciding what
>MIME type it will use to override what the server sent - some portion
>of the data is looked at too.
>
>Jim
>
>...
>> Also try hitting the aolserver from another machine with Netscape, or a
>> significantly different version of IE (I assume you use IE). I've had
>> problems with IE apparently using the file extension from the URL to
>> determine MIME type of the content, even when the server returns the
correct
>> MIME type. This occurs equally with their own IIS. You can also try
typing
>> the URL with http://myipaddress since it probably uses the syntax of the
URL
>> to decide whether to use the given MIME type or try to guess it based on
>> file extension.
