NYCPHP Meetup

[Marc Antony Vose]

>--- Marc Antony Vose <suzerain at suzerain.com> wrote:
>>  It's worth pointing out, I suppose, that to some systems (i.e.,
>>  classic Mac OS), once you tell the browser that a JPEG (or PDF in
>>  your case) is "application/octet-stream", it is no longer a JPEG
>>  (or PDF).
>
>Can you explain that? I don't understand how it could matter after 
>the resource
>has been downloaded and saved to the filesystem. Typically, the content type
>described in the HTTP response is used by the HTTP client only.
>
>I'm certainly not arguing, but I'd like that explained further if you are
>certain it is true.
>


Well, the whole file metadata thing is a huge can of worms.

So, before I say anything to explain, I'll say:  (1) This probably is 
only a problem in this instance with Classic Mac OS (meaning, prior 
to X).  Therefore, your amount of caring might be minimal.  I say, 
test it on every single browser you care about supporting, and if it 
works, then you've made your choice.

Anyway, the explanation is lengthy, and it's a hot debate in the Mac 
community right now, because Apple is (in a lot of people's minds) 
moving backwards by adopting the Windows/Unix file extension setup, 
instead of creating a more sophisticated file metadata architecture 
in the OS.

The way files are organized in Mac OS is that they have a data fork 
and a resource fork.  Unix and Windows systems don't have this, so 
generally when files from a Mac are put on a Web site, the resource 
fork is stripped.  (Mac OS X, by the way, can utilize the resource 
fork if present, and then has a backup mapping from the extension. 
This is a bit of an oversimplification, but it is pretty much 
accurate.)

Anyway, as Brian said earlier, "stupid Mac resource forks".  And, in 
this case, it sucks for the programmer, because it makes life more 
difficult if you choose to care about it.

Then again, it could be argued that calling a PDF an "octet-stream" 
just to get around file download limitations of the browser maybe 
isn't the best solution from the standpoint of interoperability and 
just "the way things ought to be done", so that everything is certain 
to work on future (as yet undesigned) systems, and so forth.

IMHO opinion, MIME types are there for a reason, and for the good of 
standards and interoperability, people should be sending out the 
proper MIME types with the file, instead of trying to fool the 
browser into doing something else.

So, if I was doing this project, my choice would probably be to ZIP 
the file, especially since ZIP files seem to be so pervasive these 
days that they are auto-extracted anyway. But, to each his/her own, 
and I am not meaning to be critical, or anything.

So, anyway, what most Mac browsers seemed to be doing (under OS 9 and 
earlier) is this:  If they received an octet stream (or a generic 
data stream), if they could determine the file type, they appeared to 
add a resource fork onto the file (sometimes) which allowed the OS to 
map the file properly.

However, many times, the file would just be downloaded and end up 
with the blank page icon which, when clicked, wouldn't open.  (I've 
specifically seen this problem with PDF files, by the way.)

Now, to get religious for a bit:

The main advantage of the resource fork becomes clear when you use a 
Mac on a daily basis.  The thing is, in Windows, if you double-click 
a JPG...any JPG...it opens with the program that's the default for 
opening JPEGs.  Obviously, this is silly, because you might want to 
have one JPEG associated with Photoshop and another associated with 
Preview, or whatever.  That's what the resource fork allows the OS to 
do:  separate the type of file from the creator of the file.

It also frees the user from stupidly having to have a file extension 
on every file.  So, you can just call your file "Letter to Bob 
Jones", rather than "Letter to Bob Jones.doc".  Just easier from a 
user's standpoint.

There was a lengthy article on ArsTechnica about this a while ago.

I have my own opinions on file metadata which I won't go into now.  ;)

Cheers,

Marc