Re: [PHP] Problems with Zip+IE6

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

Relevant Pages

  • Re: [PHP] Problems with Zip+IE6
    ... I would even say you're bound to hit a browser configured for some ... original HTTP RFC spec. ... Content-Disposition Issues: ... RFC 1806, from which the often implemented Content-Disposition ...
    (php.general)
  • Re: How to write something to a html textfield and send it?
    ... > No need for controlling any particular browser. ... I'm not familiar with HTTP user ... and building the request in your program. ... The server doesn't know anything about a textfield; ...
    (comp.programming)
  • Re: Generated javascript from .pl files
    ... Because web servers might use a different HTTP specification than ... the visiting browser, so possible HTTP version conflicts arise. ... I'd like to see an otherwise usable Web client that does not support ... one that is used here does not rely on the (Content-* request) HTTP headers. ...
    (comp.lang.javascript)
  • Re: Run As/Domain Login Windows XP Home
    ... I access my company's exchange webmail service also via a browser ... ... relate to some sophisticated user concept encapsulated in arbirtrary HTTP ... in Information Security. ...
    (Security-Basics)
  • Re: LSP HTTP redirecting
    ... In WSPSend you have access to the data that is being passed over the net, ... that means all the HTTP traffic is vizible to you. ... If you want to redirect the browser write proxy server. ...
    (microsoft.public.win32.programmer.networks)