Re: [PHP] Problems with Zip+IE6
On Sat, December 16, 2006 6:17 am, Roman Neuhauser wrote: # [EMAIL PROTECTED] / 2006-12-15 22:55:54 -0600: On Tue, December 12, 2006 11:04 am, Frank M. Kromann wrote: if you use: header(Content-Type: application/zip); header(Content-Disposition: attachment; filename=\somefile.zip\); That works for me with IE 6/7 and other browsers. Argh. Please read this: http://richardlynch.blogspot.com/ Go test with MORE browsers and MORE OSes, because you haven't yet hit the ones where your Content-Disposition does not work, and they are out there somewhere. As if it mattered that much. The filename's just a hint, the browser can be configured to ignore it even if it understands it, whatever. I would even say you're bound to hit a browser configured for some unintelligent reason to handle all app/o-s files with winamp. So what? You cannot count on anything the UA will/not do to the content. If the browser ignores application/octet-stream and doesn't do a download, it's broken. 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! A standard that is clear-cut, with no wiggle room for mis-interpretation whatsoever. What filename will any sane browser use for: http://example.com/dir1/dir2/iwant.xyz BTW, the 1995 johnny-come-lately Microsoft made-up Content-disposition header has been proposed for MIME by Qualcomm (RFC1806, RFC2183). HTTP/1.1 (RFC2616) says: 15.5 Content-Disposition Issues: RFC 1806 [35], from which the often implemented Content-Disposition (see section 19.5.1) header in HTTP is derived, has a number of very serious security considerations. Content-Disposition is not part of the HTTP standard, but since it is widely implemented, we are documenting its use and risks for implementors. See RFC 2183 [49] (which updates RFC 1806) for details. [...] 19.5.1 Content-Disposition The Content-Disposition response-header field has been proposed as a means for the origin server to suggest a default filename if the user requests that the content is saved to a file. This usage is derived from the definition of Content-Disposition in RFC 1806 [35]. content-disposition = Content-Disposition : disposition-type *( ; disposition-parm ) disposition-type = attachment | disp-extension-token disposition-parm = filename-parm | disp-extension-parm filename-parm = filename = quoted-string disp-extension-token = token disp-extension-parm = token = ( token | quoted-string ) An example is Content-Disposition: attachment; filename=fname.ext The receiving user agent SHOULD NOT respect any directory path information present in the filename-parm parameter, which is the only parameter believed to apply to HTTP implementations at this time. The filename SHOULD be treated as a terminal component only. If this header is used in a response with the application/octet- stream content-type, the implied suggestion is that the user agent should not display the response, but directly enter a `save response as...' dialog. See section 15.5 for Content-Disposition security issues. If you read between the lines, what you will find is that Qualcomm essentially asked for an RFC to standardize the stupid behaviour of MS IE, which was using Content-Disposition, originally conceived for MIME Email, and not HTTP at all. Fact is, the browsers didn't really pick up and run with this RFC for a long time. 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. 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! Not to mention the aforementioned security considerations they noted. There are so many inherent internal inconsistencies with this RFC if you think about the HTTP interaction and how UA and server works, I'm amazed Qualcomm even put their name on it. But I guess they preferred that to living with the un-documented behaviour of IE. Bottom Line: Content-Disposition will come back to bite you on the butt sooner or later. -- 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
Re: [PHP] Problems with Zip+IE6
# [EMAIL PROTECTED] / 2006-12-18 15:00:48 -0600: On Sat, December 16, 2006 6:17 am, Roman Neuhauser wrote: # [EMAIL PROTECTED] / 2006-12-15 22:55:54 -0600: On Tue, December 12, 2006 11:04 am, Frank M. Kromann wrote: if you use: header(Content-Type: application/zip); header(Content-Disposition: attachment; filename=\somefile.zip\); That works for me with IE 6/7 and other browsers. Argh. Please read this: http://richardlynch.blogspot.com/ Go test with MORE browsers and MORE OSes, because you haven't yet hit the ones where your Content-Disposition does not work, and they are out there somewhere. As if it mattered that much. The filename's just a hint, the browser can be configured to ignore it even if it understands it, whatever. I would even say you're bound to hit a browser configured for some unintelligent reason to handle all app/o-s files with winamp. So what? You cannot count on anything the UA will/not do to the content. If the browser ignores application/octet-stream and doesn't do a download, it's broken. I think you missed my point, which was: broken software is. 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! A standard that is clear-cut, with no wiggle room for mis-interpretation whatsoever. The only mention of a/o-s in HTTP 1.0 or 1.1 is this (1.1 version): 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. HTTP actually defers to MIME for the CT entity header values. a/o-s was actually proposed in RFC1341 (obsoleted by RFC1521), the latter says: application -- some other kind of data, typically either uninterpreted binary data or information to be processed by a mail-based application. The primary subtype, octet-stream, is to be used in the case of uninterpreted binary data, in which case the simplest recommended action is to offer to write the information into a file for the user. and: RFC 1341 also defined the use of a NAME parameter which gave a suggested file name to be used if the data were to be written to a file. This has been deprecated in anticipation of a separate Content-Disposition header field, to be defined in a subsequent RFC. The recommended action for an implementation that receives application/octet-stream mail is to simply offer to put the data in a file, with any Content-Transfer-Encoding undone, or perhaps to use it as input to a user-specified process. What filename will any sane browser use for: http://example.com/dir1/dir2/iwant.xyz HTTP doesn't discuss this at all, as far as I can tell. [RFC2616 quote] If you read between the lines, what you will find is that Qualcomm essentially asked for an RFC to standardize the stupid behaviour of MS IE, which was using Content-Disposition, originally conceived for MIME Email, and not HTTP at all. Qualcomm simply wanted to standardize something it badly needed for Eudora. 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. 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! Now you've completely discredited yourself. -- 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
Re: [PHP] Problems with Zip+IE6
# [EMAIL PROTECTED] / 2006-12-15 22:55:54 -0600: On Tue, December 12, 2006 11:04 am, Frank M. Kromann wrote: if you use: header(Content-Type: application/zip); header(Content-Disposition: attachment; filename=\somefile.zip\); That works for me with IE 6/7 and other browsers. Argh. Please read this: http://richardlynch.blogspot.com/ Go test with MORE browsers and MORE OSes, because you haven't yet hit the ones where your Content-Disposition does not work, and they are out there somewhere. As if it mattered that much. The filename's just a hint, the browser can be configured to ignore it even if it understands it, whatever. I would even say you're bound to hit a browser configured for some unintelligent reason to handle all app/o-s files with winamp. So what? You cannot count on anything the UA will/not do to the content. BTW, the 1995 johnny-come-lately Microsoft made-up Content-disposition header has been proposed for MIME by Qualcomm (RFC1806, RFC2183). HTTP/1.1 (RFC2616) says: 15.5 Content-Disposition Issues: RFC 1806 [35], from which the often implemented Content-Disposition (see section 19.5.1) header in HTTP is derived, has a number of very serious security considerations. Content-Disposition is not part of the HTTP standard, but since it is widely implemented, we are documenting its use and risks for implementors. See RFC 2183 [49] (which updates RFC 1806) for details. [...] 19.5.1 Content-Disposition The Content-Disposition response-header field has been proposed as a means for the origin server to suggest a default filename if the user requests that the content is saved to a file. This usage is derived from the definition of Content-Disposition in RFC 1806 [35]. content-disposition = Content-Disposition : disposition-type *( ; disposition-parm ) disposition-type = attachment | disp-extension-token disposition-parm = filename-parm | disp-extension-parm filename-parm = filename = quoted-string disp-extension-token = token disp-extension-parm = token = ( token | quoted-string ) An example is Content-Disposition: attachment; filename=fname.ext The receiving user agent SHOULD NOT respect any directory path information present in the filename-parm parameter, which is the only parameter believed to apply to HTTP implementations at this time. The filename SHOULD be treated as a terminal component only. If this header is used in a response with the application/octet- stream content-type, the implied suggestion is that the user agent should not display the response, but directly enter a `save response as...' dialog. See section 15.5 for Content-Disposition security issues. -- 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
Re: [PHP] Problems with Zip+IE6
On Tue, December 12, 2006 4:34 am, Javier Ruiz wrote: damn! that's a pretty good article, thanks a lot. unfortunatelly, it's not mentioning about zip files concretely, I didn't find a solution for my problem with them. I tried playing a bit with the Content-type, but it seems that Internet Explorer doesn't really care about Content-type... it uses the extention of the file to determine the type (microsoft's way...) so it doesn't matter if I use application/octet-stream or even application/force-download or application/makethisdownload-or-ikillyou :-D as long as I name the file whatever.zip, IE6 shows the open with dialog and if I use open with an application, it fails :( It does matter on real browsers... Use the correct content type for a download: application/octet-stream thanks again Richard for the answer and for the article :) anybody with a miracle for the ZIP+IE problem?? You're going to HAVE to open the Zip file with some kind of unzip application such as WinZip, pkunzip, or, possibly, that goofball Windows unzip thingie that lets you pretend zip archives are directories, even though they aren't, but only up to a certain point, as you can't do some things with files in the zip archive that you can do with normal files, so it's just a very confusing Human Interface... Sort of like Windows in a microcosm. If you were hoping that somehow IE would magically unzip the item, and then let you open the contents within the zip file with a chosen application... Even MS Windows isn't THAT stupid. Yet. What if there are 2 things in the zip archive? For that matter, if there aren't 2 things, why is it even zipped? 1 - To change the mimetype (when writting http headers) from application/zip that I used before to application/x-zip-compressed 2 - To not use MOD_DEFLATE in apache2 (I was not using it really...) I now am beginning to wonder if you are trying to send your HTML as gzip'ed data for the browser to surf to your site, to save on bandwidth... If so, none of the above has any bearing on this at all... -- 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
Re: [PHP] Problems with Zip+IE6
On Tue, December 12, 2006 11:04 am, Frank M. Kromann wrote: if you use: header(Content-Type: application/zip); header(Content-Disposition: attachment; filename=\somefile.zip\); That works for me with IE 6/7 and other browsers. Argh. Please read this: http://richardlynch.blogspot.com/ Go test with MORE browsers and MORE OSes, because you haven't yet hit the ones where your Content-Disposition does not work, and they are out there somewhere. -- 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
Re: [PHP] Problems with Zip+IE6
damn! that's a pretty good article, thanks a lot. unfortunatelly, it's not mentioning about zip files concretely, I didn't find a solution for my problem with them. I tried playing a bit with the Content-type, but it seems that Internet Explorer doesn't really care about Content-type... it uses the extention of the file to determine the type (microsoft's way...) so it doesn't matter if I use application/octet-stream or even application/force-download or application/makethisdownload-or-ikillyou :-D as long as I name the file whatever.zip, IE6 shows the open with dialog and if I use open with an application, it fails :( thanks again Richard for the answer and for the article :) anybody with a miracle for the ZIP+IE problem?? On 12/5/06, Richard Lynch [EMAIL PROTECTED] wrote: It's kinda long, but this will probably save you some grief: http://richardlynch.blogspot.com On Tue, December 5, 2006 2:07 am, Javier Ruiz wrote: Hi all! I have a problem with zip files and Internet Explorer 6. I try to send to the user a dinamically generated zip file writting the http headers and using file_put_contents for the zip content. It works fine when downloading the file with firefox, opera, etc... even it works well if I download the file with internet explorer and then open it with any zip tool. The problem comes when I try to directly open the file from the URL using IE6. I found this is a known bug of IE (several versions) in windows XP: http://support.microsoft.com/kb/308090 Does anybody know any way to workaround this problem? I found a couple workarounds in forums over there and I tried them, but unfortunately they didn't work: 1 - To change the mimetype (when writting http headers) from application/zip that I used before to application/x-zip-compressed 2 - To not use MOD_DEFLATE in apache2 (I was not using it really...) Any idea?? Thanks a lot! -- 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?
Re: [PHP] Problems with Zip+IE6
Hello, if you use: header(Content-Type: application/zip); header(Content-Disposition: attachment; filename=\somefile.zip\); That works for me with IE 6/7 and other browsers. - Frank damn! that's a pretty good article, thanks a lot. unfortunatelly, it's not mentioning about zip files concretely, I didn't find a solution for my problem with them. I tried playing a bit with the Content-type, but it seems that Internet Explorer doesn't really care about Content-type... it uses the extention of the file to determine the type (microsoft's way...) so it doesn't matter if I use application/octet-stream or even application/force-download or application/makethisdownload-or-ikillyou :-D as long as I name the file whatever.zip, IE6 shows the open with dialog and if I use open with an application, it fails :( thanks again Richard for the answer and for the article :) anybody with a miracle for the ZIP+IE problem?? On 12/5/06, Richard Lynch [EMAIL PROTECTED] wrote: It's kinda long, but this will probably save you some grief: http://richardlynch.blogspot.com On Tue, December 5, 2006 2:07 am, Javier Ruiz wrote: Hi all! I have a problem with zip files and Internet Explorer 6. I try to send to the user a dinamically generated zip file writting the http headers and using file_put_contents for the zip content. It works fine when downloading the file with firefox, opera, etc... even it works well if I download the file with internet explorer and then open it with any zip tool. The problem comes when I try to directly open the file from the URL using IE6. I found this is a known bug of IE (several versions) in windows XP: http://support.microsoft.com/kb/308090 Does anybody know any way to workaround this problem? I found a couple workarounds in forums over there and I tried them, but unfortunately they didn't work: 1 - To change the mimetype (when writting http headers) from application/zip that I used before to application/x-zip-compressed 2 - To not use MOD_DEFLATE in apache2 (I was not using it really...) Any idea?? Thanks a lot! -- 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
Re: [PHP] Problems with Zip+IE6
It's kinda long, but this will probably save you some grief: http://richardlynch.blogspot.com On Tue, December 5, 2006 2:07 am, Javier Ruiz wrote: Hi all! I have a problem with zip files and Internet Explorer 6. I try to send to the user a dinamically generated zip file writting the http headers and using file_put_contents for the zip content. It works fine when downloading the file with firefox, opera, etc... even it works well if I download the file with internet explorer and then open it with any zip tool. The problem comes when I try to directly open the file from the URL using IE6. I found this is a known bug of IE (several versions) in windows XP: http://support.microsoft.com/kb/308090 Does anybody know any way to workaround this problem? I found a couple workarounds in forums over there and I tried them, but unfortunately they didn't work: 1 - To change the mimetype (when writting http headers) from application/zip that I used before to application/x-zip-compressed 2 - To not use MOD_DEFLATE in apache2 (I was not using it really...) Any idea?? Thanks a lot! -- 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
