Microsoft's "I mean it" content-type parameter

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
97 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

Microsoft's "I mean it" content-type parameter

Julian Reschke

Hi,

(crossposted to both the HTTPbis WG's and HTML5 WG's mailing lists...)

looking at
<http://blogs.msdn.com/ie/archive/2008/07/02/ie8-security-part-v-comprehensive-protection.aspx>:

"MIME-Handling: Sniffing Opt-Out

Next, we’ve provided web-applications with the ability to opt-out of
MIME-sniffing. Sending the new authoritative=true attribute on the
Content-Type HTTP response header prevents Internet Explorer from
MIME-sniffing a response away from the declared content-type."

Let's ignore the issue of inventing a new media type parameter for all
new media types for a moment...

It's good that MS recognizes that content-type-sniffing may be bad and
that they are doing something about it. But is this really the right
approach?

BR, Julian

Reply | Threaded
Open this post in threaded view
|

Re: Microsoft's "I mean it" content-type parameter

Robert Collins
On Wed, 2008-07-02 at 22:52 +0200, Julian Reschke wrote:

> Hi,
>
> (crossposted to both the HTTPbis WG's and HTML5 WG's mailing lists...)
>
> looking at
> <http://blogs.msdn.com/ie/archive/2008/07/02/ie8-security-part-v-comprehensive-protection.aspx>:
>
> "MIME-Handling: Sniffing Opt-Out
>
> Next, we’ve provided web-applications with the ability to opt-out of
> MIME-sniffing. Sending the new authoritative=true attribute on the
> Content-Type HTTP response header prevents Internet Explorer from
> MIME-sniffing a response away from the declared content-type."
>
> Let's ignore the issue of inventing a new media type parameter for all
> new media types for a moment...
>
> It's good that MS recognizes that content-type-sniffing may be bad and
> that they are doing something about it. But is this really the right
> approach?
If they assume that fixing all the bust clients they have been shipping
for years is infeasible, then I think they would have concluded its the
right way.

I think its bogus - it requires every web site author in existence to
change their site to fix a defect in MSIE. Thats got to be harder to
deploy than just a hotfix to MSIE to not sniff at all. 'Sorry, bad idea,
fixed in hotfix #12345.'

-Rob
--
GPG key available at: <http://www.robertcollins.net/keys.txt>.

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Microsoft's "I mean it" content-type parameter

Julian Reschke

Robert Collins wrote:

> ...
> If they assume that fixing all the bust clients they have been shipping
> for years is infeasible, then I think they would have concluded its the
> right way.
>
> I think its bogus - it requires every web site author in existence to
> change their site to fix a defect in MSIE. Thats got to be harder to
> deploy than just a hotfix to MSIE to not sniff at all. 'Sorry, bad idea,
> fixed in hotfix #12345.'
> ...

Well, not only MS is guilty of sniffing (although they may have started
it), and the HTML5 spec has lots of details on how to do it
(<http://www.w3.org/html/wg/html5/#content-type-sniffing>), although it
at least allows UAs not to sniff (*).

BR, Julian

(*) Need to check: is this the case throughout the spec, or are there
exceptions?

Reply | Threaded
Open this post in threaded view
|

Re: Microsoft's "I mean it" content-type parameter

Frank Ellermann
In reply to this post by Julian Reschke

Julian Reschke wrote:
 
>| MIME-Handling: Sniffing Opt-Out

"Opt-out" and "embrace" should be put under Godwin's Law.

For their text/plain example, why can't they add an "try
to render as HTML" OPTIoN ?  OE6 can manage this issue
as I want it, admittedly I wasn't aware that IE6 doesn't.
And IE8 can do whatever makes sense wrt security.

> Let's ignore the issue of inventing a new media type
> parameter for all new media types for a moment...

<moment for="a" />  No ;-)  As your subject says, this
"I mean it" parameter has the decent charme of RFC 3514:
| The Security Flag in the IPv4 Header (Evil Bit).
| S. Bellovin. 1 April 2003.

> But is this really the right approach?

Assuming that HTTP servers know what they are talking
about is arguably no OPTIoN... :-(

 Frank


Reply | Threaded
Open this post in threaded view
|

Re: Microsoft's "I mean it" content-type parameter

William A. Rowe Jr.
In reply to this post by Robert Collins

Robert Collins wrote:
> On Wed, 2008-07-02 at 22:52 +0200, Julian Reschke wrote:
>>
>> Let's ignore the issue of inventing a new media type parameter for all
>> new media types for a moment...

And ignore the fact that the content may not be proxied properly?  I think
that's a pretty silly detail to ignore.

>> It's good that MS recognizes that content-type-sniffing may be bad and
>> that they are doing something about it. But is this really the right
>> approach?
>
> If they assume that fixing all the bust clients they have been shipping
> for years is infeasible, then I think they would have concluded its the
> right way.

Of course, this repairs all the bust clients no more effectively than
changing their behavior to conform to RFC2616 in the first place.

> I think its bogus - it requires every web site author in existence to
> change their site to fix a defect in MSIE. Thats got to be harder to
> deploy than just a hotfix to MSIE to not sniff at all. 'Sorry, bad idea,
> fixed in hotfix #12345.'

Well, at least every administrator.

I find this statement from the blog very telling;

"For instance, if Internet Explorer finds HTML content in a file delivered
with the HTTP response header Content-Type: text/plain, IE determines that
the content should be rendered as HTML. Because of the number of legacy
servers on the web (e.g. those that serve all files as text/plain)
MIME-sniffing is an important compatibility feature."

It would be very fun to see the example they cite, I sincerely doubt they
exist to any legitimate extent today.  Our friends crawling the web could
probably give us hard numbers.  I suspect the short history goes;

  * some folks start serving files over http:, associate .html with text/html

  * 1000's download ms authoring tools to create default.htm files

  * 100's uploading to these "ancient" servers discover they render as either
    binary/octet-stream or text/plain

  * MS fixes their client to display .htm files as html

Interestingly, they don't work around the fact that all of these servers are
also configured to serve index.html and not default.htm.  If they relied on
the administrators to fix one side of the coin...

Of course I don't think the example tells the story.  Embedded client side
execution of a host of MS formats further poisoned the ecosystem, which
was far more important to Microsoft than ensuring text/plain renders as
html.  Nobel purposes, for a utopian web of trustworthy content providers.

This makes no more sense than their lifting Content-Disposition into http,
but there you go, it's there.  Until more major MS customers move entirely
to Firefox or other alternatives, I don't anticipate this patchwork approach
changing.  And few content providers are so lucky as to dictate their
browser client.

It certainly hasn't enjoyed peer scrutiny, though, and I doubt MS will ask
for it.  They are likely to get it in the blogosphere, however.


Reply | Threaded
Open this post in threaded view
|

Re: Microsoft's "I mean it" content-type parameter

Julian Reschke

William A. Rowe, Jr. wrote:
> ...
>> If they assume that fixing all the bust clients they have been shipping
>> for years is infeasible, then I think they would have concluded its the
>> right way.
>
> Of course, this repairs all the bust clients no more effectively than
> changing their behavior to conform to RFC2616 in the first place.
> ...

Many more clients to content sniffing, and the HTML5 draft suggests it's
  the right thing to do...

>> I think its bogus - it requires every web site author in existence to
>> change their site to fix a defect in MSIE. Thats got to be harder to
>> deploy than just a hotfix to MSIE to not sniff at all. 'Sorry, bad idea,
>> fixed in hotfix #12345.'
>
> Well, at least every administrator.
>
> I find this statement from the blog very telling;
>
> "For instance, if Internet Explorer finds HTML content in a file delivered
> with the HTTP response header Content-Type: text/plain, IE determines that
> the content should be rendered as HTML. Because of the number of legacy
> servers on the web (e.g. those that serve all files as text/plain)
> MIME-sniffing is an important compatibility feature."
>
> It would be very fun to see the example they cite, I sincerely doubt they
> exist to any legitimate extent today.  Our friends crawling the web could
> probably give us hard numbers.  I suspect the short history goes;
> ...

As a matter of fact, I can't even reproduce that *specific* case with
IE6 and IE7, see
<http://hixie.ch/tests/adhoc/http/content-type/013.html>. Not sure what
I'm missing here...

 > ...
> This makes no more sense than their lifting Content-Disposition into http,
> but there you go, it's there.  Until more major MS customers move entirely
> to Firefox or other alternatives, I don't anticipate this patchwork
> approach
> changing.  And few content providers are so lucky as to dictate their
> browser client.
> ...

Hm, what does this have to do with Content-Disposition?

> ...

BR, Julian

Reply | Threaded
Open this post in threaded view
|

Re: Microsoft's "I mean it" content-type parameter

Frank Ellermann

Julian Reschke wrote:
 
> I can't even reproduce that *specific* case with IE6 and IE7,
> see <http://hixie.ch/tests/adhoc/http/content-type/013.html>.
> Not sure what I'm missing here...

...my IE6 says that you missed 014.html on the same server :-)

 Frank


Reply | Threaded
Open this post in threaded view
|

Re: Microsoft's "I mean it" content-type parameter

Julian Reschke

Frank Ellermann wrote:
> Julian Reschke wrote:
>  
>> I can't even reproduce that *specific* case with IE6 and IE7,
>> see <http://hixie.ch/tests/adhoc/http/content-type/013.html>.
>> Not sure what I'm missing here...
>
> ...my IE6 says that you missed 014.html on the same server :-)

Indeed. But it does display as plain text in IE7.

BR, Julian

Reply | Threaded
Open this post in threaded view
|

Re: Microsoft's "I mean it" content-type parameter

Jamie Lokier
In reply to this post by Julian Reschke

Julian Reschke wrote:
> Many more clients to content sniffing, and the HTML5 draft suggests it's
>  the right thing to do...

So this whole question can be rephrased thus:

   Are there significant numbers of servers out there which are
   serving content intended to be rendered as HTML (or other) with
   Content-Type: text/plain?

> >>I think its bogus - it requires every web site author in existence to
> >>change their site to fix a defect in MSIE. Thats got to be harder to
> >>deploy than just a hotfix to MSIE to not sniff at all.

Perhaps.  On the other hand, presumably the IE sniffing heuristic has
worked fine for many years with most sites, therefore it *doesn't*
require most site authors to do anything at all.

> >"For instance, if Internet Explorer finds HTML content in a file delivered
> >with the HTTP response header Content-Type: text/plain, IE determines that
> >the content should be rendered as HTML. Because of the number of legacy
> >servers on the web (e.g. those that serve all files as text/plain)
> >MIME-sniffing is an important compatibility feature."
> >
> >It would be very fun to see the example they cite, I sincerely doubt they
> >exist to any legitimate extent today.

What about all HTTP->FTP proxies?  FTP doesn't have Content-Type.  Do
proxies themselves add Content-Type by sniffing what they are forwarding?

I suspect this IE sniffing came out of compatibility with what the
browser must do when viewing FTP servers and local filesystems, by the
way.  On both of those, the browser must either sniff the content,
and/or sniff the filename, to decide the content type (and charset).

Also, it might it be invoked by servers which report *no* Content-Type?

> >Our friends crawling the web could probably give us hard numbers.

Hard numbers would be good.

-- Jamie


  I suspect the short history goes;

> >...
>
> As a matter of fact, I can't even reproduce that *specific* case with
> IE6 and IE7, see
> <http://hixie.ch/tests/adhoc/http/content-type/013.html>. Not sure what
> I'm missing here...
>
> > ...
> >This makes no more sense than their lifting Content-Disposition into http,
> >but there you go, it's there.  Until more major MS customers move entirely
> >to Firefox or other alternatives, I don't anticipate this patchwork
> >approach
> >changing.  And few content providers are so lucky as to dictate their
> >browser client.
> >...
>
> Hm, what does this have to do with Content-Disposition?
>
> >...
>
> BR, Julian
>

Reply | Threaded
Open this post in threaded view
|

Re: Microsoft's "I mean it" content-type parameter

Julian Reschke

Jamie Lokier wrote:
> Julian Reschke wrote:
>> Many more clients to content sniffing, and the HTML5 draft suggests it's
>>  the right thing to do...
>
> So this whole question can be rephrased thus:
>
>    Are there significant numbers of servers out there which are
>    serving content intended to be rendered as HTML (or other) with
>    Content-Type: text/plain?

I fear so, because of Apache httpd's support for defaulting the content
type (and the default being text/plain).

See <https://issues.apache.org/bugzilla/show_bug.cgi?id=13986>.

> ...
> Also, it might it be invoked by servers which report *no* Content-Type?
> ...

Well, that's totally ok. Servers that do not know the Content-Type of a
resource should not guess, which in turn allows the recipient to sniff.

> ...

BR, Julian

Reply | Threaded
Open this post in threaded view
|

RE: Microsoft's "I mean it" content-type parameter

Justin James-2
In reply to this post by William A. Rowe Jr.

> It would be very fun to see the example they cite, I sincerely doubt they
> exist to any legitimate extent today.  Our friends crawling the web could
> probably give us hard numbers.  I suspect the short history goes;
>
>   * some folks start serving files over http:, associate .html with text/html
>
>   * 1000's download ms authoring tools to create default.htm files
>
>   * 100's uploading to these "ancient" servers discover they render as either
>     binary/octet-stream or text/plain
>
>   * MS fixes their client to display .htm files as html
>
> Interestingly, they don't work around the fact that all of these servers are
> also configured to serve index.html and not default.htm.  If they relied on
> the administrators to fix one side of the coin...

William -

There are tons of legitimate use cases here they you have completely overlooked. For example, lots of server side applications throw out content of a type different from what their file extension would indicate. For example, the earliest "hit counter" programs were .cgi or .pl files (typically) generating image/gif or image/jpeg content. The Web servers were set up explicitly to serve the output of those applications as text/html. And a great many developers had no idea that they needed to change the Content-type at the code level to make this work. Content sniffing made life easier for these developers. Indeed, Content-disposition is a brutally critical header for any developer making, say, a file download application that actually spews forth the bits itself instead of performing a redirection.

J.Ja


Reply | Threaded
Open this post in threaded view
|

RE: Microsoft's "I mean it" content-type parameter

Daniel Stenberg

On Thu, 3 Jul 2008, Justin James wrote:

> There are tons of legitimate use cases here they you have completely
> overlooked. For example, lots of server side applications throw out content
> of a type different from what their file extension would indicate. For
> example, the earliest "hit counter" programs were .cgi or .pl files
> (typically) generating image/gif or image/jpeg content. The Web servers were
> set up explicitly to serve the output of those applications as text/html.
> And a great many developers had no idea that they needed to change the
> Content-type at the code level to make this work. Content sniffing made life
> easier for these developers.

Uh, that doesn't make sense.

Sure, some scripts output wrong Content-Type. Then no browser can output it
correctly and thus you fix the server side.

But, this system with bad Content-Type outputs still showing up nicely only
works if the client *already* have does this "sniffing" business and thus they
more or less encouraged the server-side hackers to remain sloppy.

So this cannot have been a case where the browser adapted to how servers work,
since servers would hardly ever have worked this way if some browsers didn't
already support it...

I find this "I promise this time I really mean that the type is what I say"
attribute hilariously funny.

--

  / daniel.haxx.se

Reply | Threaded
Open this post in threaded view
|

RE: Microsoft's "I mean it" content-type parameter

Justin James-2

Daniel -

The *entire* Web is founded on sloppy programmers, what makes you think that
this scenario is an exception? If browser vendors didn't create browsers
that accepted any semi-reasonable slop served out, then the Web would still
just be TBL and a few scientists who were used to Postscript being delighted
at how "simple" HTML is (while the public has proven how hard it is to write
valid HTML) to pass around their academic papers. :)

But you are right about there being a chicken/egg issue here in my
particular example. I am *positive* that Apache's behavior of throwing
everything out at text/html unless explicitly specified otherwise with a
MIME mapping or in the headers from a CGI had a lot to do with it, which
Julian already explained.

I don't think the proposal is a good one either, for the record. I also
don't think it is a bad one. It doesn't break anything, and it extends the
protocol in a way that does not cause any problems to existing stuff, and it
will only be used by a small fraction of people.

J.Ja

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On
Behalf Of Daniel Stenberg
Sent: Thursday, July 03, 2008 11:52 AM
To: 'HTTP Working Group'
Cc: [hidden email]
Subject: RE: Microsoft's "I mean it" content-type parameter


On Thu, 3 Jul 2008, Justin James wrote:

> There are tons of legitimate use cases here they you have completely
> overlooked. For example, lots of server side applications throw out
content
> of a type different from what their file extension would indicate. For
> example, the earliest "hit counter" programs were .cgi or .pl files
> (typically) generating image/gif or image/jpeg content. The Web servers
were
> set up explicitly to serve the output of those applications as text/html.
> And a great many developers had no idea that they needed to change the
> Content-type at the code level to make this work. Content sniffing made
life
> easier for these developers.

Uh, that doesn't make sense.

Sure, some scripts output wrong Content-Type. Then no browser can output it
correctly and thus you fix the server side.

But, this system with bad Content-Type outputs still showing up nicely only
works if the client *already* have does this "sniffing" business and thus
they
more or less encouraged the server-side hackers to remain sloppy.

So this cannot have been a case where the browser adapted to how servers
work,
since servers would hardly ever have worked this way if some browsers didn't

already support it...

I find this "I promise this time I really mean that the type is what I say"
attribute hilariously funny.

--

  / daniel.haxx.se


Reply | Threaded
Open this post in threaded view
|

Re: Microsoft's "I mean it" content-type parameter

David Singer
In reply to this post by Julian Reschke

At 15:43  +0200 3/07/08, Julian Reschke wrote:

>Jamie Lokier wrote:
>>Julian Reschke wrote:
>>>Many more clients to content sniffing, and the HTML5 draft
>>>suggests it's  the right thing to do...
>>
>>So this whole question can be rephrased thus:
>>
>>    Are there significant numbers of servers out there which are
>>    serving content intended to be rendered as HTML (or other) with
>>    Content-Type: text/plain?
>
>I fear so, because of Apache httpd's support for defaulting the
>content type (and the default being text/plain).
>
>See <https://issues.apache.org/bugzilla/show_bug.cgi?id=13986>.
>
>>...
>>Also, it might it be invoked by servers which report *no* Content-Type?
>>...
>
>Well, that's totally ok. Servers that do not know the Content-Type
>of a resource should not guess, which in turn allows the recipient
>to sniff.

but, as far as I can tell, there is no "unknown" content-type, is there?


--
David Singer
Apple/QuickTime

Reply | Threaded
Open this post in threaded view
|

Re: Microsoft's "I mean it" content-type parameter

Julian Reschke

Dave Singer wrote:
>>> ...
>>> Also, it might it be invoked by servers which report *no* Content-Type?
>>> ...
>>
>> Well, that's totally ok. Servers that do not know the Content-Type of
>> a resource should not guess, which in turn allows the recipient to sniff.
>
> but, as far as I can tell, there is no "unknown" content-type, is there?

The way to signal "unknown" is not to send a Content-Type header at all.
As far as I understand, this is what happens with httpd trunk when you
set the DefaultType to "none".

BR, Julian


Reply | Threaded
Open this post in threaded view
|

Re: Microsoft's "I mean it" content-type parameter

David Singer

At 18:17  +0200 3/07/08, Julian Reschke wrote:

>Dave Singer wrote:
>>>>...
>>>>Also, it might it be invoked by servers which report *no* Content-Type?
>>>>...
>>>
>>>Well, that's totally ok. Servers that do not know the Content-Type
>>>of a resource should not guess, which in turn allows the recipient
>>>to sniff.
>>
>>but, as far as I can tell, there is no "unknown" content-type, is there?
>
>The way to signal "unknown" is not to send a Content-Type header at
>all. As far as I understand, this is what happens with httpd trunk
>when you set the DefaultType to "none".

or, it seems, "application/octet-stream".  From HTTP 1.1:

Any HTTP/1.1 message containing an entity-body SHOULD include a
Content-Type header field defining the media type of that body. If
and only if the media type is not given by a Content-Type field, the
recipient MAY attempt to guess the media type via inspection of its
content and/or the name extension(s) of the URI used to identify the
resource. If the media type remains unknown, the recipient SHOULD
treat it as type "application/octet-stream".

It does seem as if sniffing when there is a content-type header is
flat-out forbidden.  I.e. the presence of content-type was supposed
to serve *exactly* what the "I mean it" extension is doing...

Next up:  a server that always adds the "I mean it" attribute, even
when it doesn't, and the subsequent invention of the "No, really,
come on, you have to believe me, scout's honor, I really truly mean
it" extension.
--
David Singer
Apple/QuickTime

Reply | Threaded
Open this post in threaded view
|

Re: Microsoft's "I mean it" content-type parameter

Julian Reschke

Dave Singer wrote:
> ...
> Next up:  a server that always adds the "I mean it" attribute, even when
> it doesn't, and the subsequent invention of the "No, really, come on,
> you have to believe me, scout's honor, I really truly mean it" extension.
 > ...

Of course. That's why we usually do not define specific error recovery
in HTTPbis. First of all, mandating a very specific error recovery (1)
may not be the right thing for all use cases, (2) it blurs the boundary
between valid and invalid (if the behavior for invalid is mandatory,
where's the point in producing valid messages), and (3), as you said, in
the end you'll have to define error recovery for the error recovery...

BR, Julian

Reply | Threaded
Open this post in threaded view
|

Re: Microsoft's "I mean it" content-type parameter

Jamie Lokier
In reply to this post by Justin James-2

Justin James wrote:
> The *entire* Web is founded on sloppy programmers,

Indeed, just look at HTML5 potentially taking over from XHTML.  It's
practically reincarnating sloppiness, admitting defeat with XHTML,
this time trying to formalise how to handle slop so at least we do it
all the same.

(But last time I looked, it didn't handle slop the same way as certain
major browsers, but rather according to what the HTML5 authors thought
would be sensible, so that part seems doomed to be not implemented
according to spec, but as Yet Another incompatible compatibility layer
in real browsers.)

-- Jamie

Reply | Threaded
Open this post in threaded view
|

Re: Microsoft's "I mean it" content-type parameter

Julian Reschke
In reply to this post by Julian Reschke

Julian Reschke wrote:
> ...
> As a matter of fact, I can't even reproduce that *specific* case with
> IE6 and IE7, see
> <http://hixie.ch/tests/adhoc/http/content-type/013.html>. Not sure what
> I'm missing here...
> ...

FYI, see
<http://blogs.msdn.com/ie/archive/2008/07/02/ie8-security-part-v-comprehensive-protection.aspx#8684670>
-- it's because the tag IE's is sniffing for does not occur in the first
256 bytes.

BR, Julian

Reply | Threaded
Open this post in threaded view
|

Re: Microsoft's "I mean it" content-type parameter

Roy T. Fielding
In reply to this post by Justin James-2

On Jul 3, 2008, at 9:04 AM, Justin James wrote:

> The *entire* Web is founded on sloppy programmers, what makes you  
> think that
> this scenario is an exception? If browser vendors didn't create  
> browsers
> that accepted any semi-reasonable slop served out, then the Web  
> would still
> just be TBL and a few scientists who were used to Postscript being  
> delighted
> at how "simple" HTML is (while the public has proven how hard it is  
> to write
> valid HTML) to pass around their academic papers. :)

Whoa, talk about revisionist history.  There was no significant  
sloppyness
in content types on the web until after IE3 came out with that bug, and
the reason they did so had nothing to do with the content on servers.
It was just "simpler" for them to use the same algorithm regardless of
source (what everyone else calls a security hole).  It was only later,
when Netscape and other browsers had problems with content that was  
served
at sites that only use MSIE for authoring, that sniffing by other  
browsers
became common on the Web.

> But you are right about there being a chicken/egg issue here in my
> particular example. I am *positive* that Apache's behavior of throwing
> everything out at text/html unless explicitly specified otherwise  
> with a
> MIME mapping or in the headers from a CGI had a lot to do with it,  
> which
> Julian already explained.

No, it had nothing to do with it.  Apache sends text/plain by default
because that is the desired config for files with no type extensions
on Unix filesystems.  It comes from NCSA httpd history and is very hard
to deprecate without breaking valid content that has been correctly
configured.  In any case, it has only had a negative effect on new file
formats, not defined ones like HTML, and has no effect whatsoever on  
scripts.
I've never seen a script forget to set its own content-type.

> I don't think the proposal is a good one either, for the record. I  
> also
> don't think it is a bad one. It doesn't break anything, and it  
> extends the
> protocol in a way that does not cause any problems to existing  
> stuff, and it
> will only be used by a small fraction of people.

On the contrary, if MSIE uses it to detect authoritative content, then
Apache will probably be changed to always send that parameter when
browser UA is MSIE.  Apache works around stupid browser bugs and
security holes in browsers, whether they like it or not.

....Roy

12345