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.
>>
>> Argggggh.
>>
>> 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
