On Thu, January 4, 2007 8:09 pm, Roman Neuhauser wrote: > # 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. It's a theory, more than fact, obviously, as I wasn't involved in the meetings where MS engineers decided to design/code this specific bit of IE. Consider these facts, however: MS has brain-dead simple .xyz -> file-type-handler Operating System. '.doc' extensions could have been trivially mapped to 'application/msword' or 'application/vnd.ms-word' Instead, IE falls back to a generic and content-devoid 'application/octet-stream' I suppose we could attribute this to sheer stupidity, but I'm going with malice as the operating factor. > I'm simply > fed up with his bashing MS for artificial reasons (like his foaming > over > the allegedly MS-originated Content-Disposition header). The "Content-Disposition" header was originated in MIME email. It was then abused by MS IIS for HTTP, for which it was never intended. And it *still* doesn't work across the board, no matter who made it up. > *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. I am sorry you find my posts inflammatory and non-issue with unwarranted and unasked for information. Please feel free to use the delete key. >> >> 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. Please take the time to figure out WHY QualComm wrote that RFC. Pay particular attention to the history of MIME EMAIL and HTTP server headers. Also take note: QualComm does not, to the best of my knowledge, have any invested stake in HTTP servers. MS does. MIME Email, QualComm has much invested. As with any documentation, pay attention to the players, and where their money comes from, while you read. > 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. Errrrr. One of the earliest HTTP RFCs specifically states that the client program MUST treat application/octet-stream as a file to be downloaded. Not MAY, not SHOULD. MUST. Unfortunately, I cannot find it right now, as I keep finding these stupid MIME email crap RFCs instead, which apply to email. All I know is that the RFC number is a heck of a lot lower than 1521. And I know that every web browser ever built works this way, but not every web browser ever built works with Content-Disposition, not by a long shot. > 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? MIME *email* headers, specifically introduced to deal with HTML enhanced (cough, cough) email, being back-ported to HTTP, is the stupid part. Sorry I wasn't clear. -- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some starving artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
