# ceo@xxxxxxxxx / 2006-12-18 15:00:48 -0600:
> On Sat, December 16, 2006 6:17 am, Roman Neuhauser wrote:
> > # ceo@xxxxxxxxx / 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.
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
