# 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 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
