Re: [PHP] IE, Word documents and Content Types

# jochem@xxxxxxxxxxxxx / 2007-01-04 23:36:44 +0100:
Roman Neuhauser wrote:
# ceo@xxxxxxxxx / 2007-01-03 15:48:31 -0600:
On Wed, January 3, 2007 2:52 pm, Philip Thompson wrote:
I have a form where a user can upload different types of documents. A
valid file type they will be able to upload is a Word Document.
However, when I view the $_FILES 'type' of a word document in Internet
Explorer, it says it's type 'application/octet-stream' instead of
'application/msword' or 'application/vnd.ms-word'. It works fine in
Firefox and Safari.

Any ideas why IE does this and/or how I might be able to get around
this?
IE does this because MS is not interested in interoperability.

Back this statements with some references, will you?

do a quick google on anti-trust or something. there is plenty of evidence
that Microsoft has and does continue to hamper and/or ignore interoperability
on many fronts.

Yes I know. I don't care.

I was asking if he could back his statement that IE sends CT: a/o-s to
harm interoperability. I don't care what MS did elsewhere. I'm simply
fed up with his bashing MS for artificial reasons (like his foaming over
the allegedly MS-originated Content-Disposition header).

*Especially* as the value carries no information since it's under the
control of a (potentially) malicious user (he later mentioned that
himself)! The net effect is that a naive programmer who would otherwise
merrily fall prey to an exploit has to DTRT, which is inspect the file.

That makes the whole thing a non-issue, and the opening remark was
completely unwarranted, unasked for.

Note that application/octet-stream is valid for any kind of document
whatsoever for an upload. For output, that would require the browser
to download the document rather than attempt to display it. More on
that here:
http://richardlynch.blogspot.com/

To the OP: read that rant for amusement, but don't use the "advice"
rlynch gives, it's nonsense. If you don't believe me, check the RFCs

richard's practical experience in dealing with this things is nonsense?

It's "advice", not "experience".

he has been dealing with this kind of stuff [I'm referring just to his
experience/work with php for the purpose of this reply] for longer than
most of us have even heard of php - and for companies that most of us
would give our right arm to work for. his rant is based on lots of experience
on how to make things that work, rather than making that should work because
they adhere to any/every given standard (but don't work because of any number
of real world situations)

I already wrote it:

If you don't believe me, check the RFCs

Really, please do it, I beg you. Read the RFCs I quoted in the last
installment of the Content-Disposition discussion.

Richard Lynch:

It *HAS* to prompt you for a filename and do a download, by the
original HTTP RFC spec. Please read more RFCs until you find the one
about "application/octet-stream"

If the UA opens up "application/octet-stream" it is in direct
violation of one of the few HTTP standards that every other UA on the
planet actually honors!

The HTTP standard:

Nothing, zip, nada. HTTP doesn't generally discuss presentation of entities
contained in responses.

Richard Lynch:

Not to mention that it's a STUPID thing for MS IE to have done in the
first place, to re-purpose a MIME email header for HTTP.

The HTTP standard:

HTTP/1.1 uses many of the constructs defined for Internet Mail (RFC
822 [9]) and the Multipurpose Internet Mail Extensions (MIME [7]) to
allow entities to be transmitted in an open variety of
representations and with extensible mechanisms. However, RFC 2045
discusses mail, and HTTP has a few features that are different from
those described in RFC 2045.

Indeed, how stupid of the HTTP authors to repurpose the MIME Content-Type
header! The "application/octet-stream" names a *MIME type*, FFS! Those
repurposes weren't stupid?

Richard Lynch:

It doesn't even make sense, since Content-Disposition has a MIME type
embedded in it, which may or may not match the Content-type of the
HTTP Request!


RFC 2183 defines the Content-Disposition header using a grammar which
does not include content type:

disposition := "Content-Disposition" ":"
disposition-type
*(";" disposition-parm)

disposition-type := "inline"
/ "attachment"
/ extension-token
; values are not case-sensitive

disposition-parm := filename-parm
/ creation-date-parm
/ modification-date-parm
/ read-date-parm
/ size-parm
/ parameter

In Richard's own words: it wouldn't even make sense, since MIME defines
the Content-Type header!

I hope it's clear now.

--
How many Vietnam vets does it take to screw in a light bulb?
You don't know, man. You don't KNOW.
Cause you weren't THERE. http://bash.org/?255991
.

Relevant Pages

  • Re: [PHP] Problems with Zip+IE6
    ... I would even say you're bound to hit a browser configured for some ... original HTTP RFC spec. ... Content-Disposition Issues: ... RFC 1806, from which the often implemented Content-Disposition ...
    (php.general)
  • Re: HTML rdp help
    ... see the "Content-Disposition" HTTP header. ... RFC 2616 notes that some HTTP implementations follow RFC 1806 to some ...
    (comp.programming)
  • Re: [PHP] IE, Word documents and Content Types
    ... The "Content-Disposition" header was originated in MIME email. ... It was then abused by MS IIS for HTTP, for which it was never intended. ... Please take the time to figure out WHY QualComm wrote that RFC. ...
    (php.general)
  • Re: [PHP] Problems with Zip+IE6
    ... I would even say you're bound to hit a browser configured for some ... original HTTP RFC spec. ... either uninterpreted binary data or information to ... IE, which was using Content-Disposition, originally conceived for MIME ...
    (php.general)
  • RE: [Full-Disclosure] Apparently the practice was prevalent
    ... > Agreed, but you see, RFC 2616 defines more than just the ... > HTTP protocol. ... It defines the protocol. ... security is the least of your concerns. ...
    (Full-Disclosure)