Re: MacBinary 4 format
Re: MacBinary 4 format
- Subject: Re: MacBinary 4 format
- From: David Catmull <email@hidden>
- Date: Thu, 29 Jul 2004 17:04:10 -0600
On Jul 29, 2004, at 4:47 PM, Mike Fischer wrote:
>
I agree about the usefulnes of the HTTP (1.1) protocol but that
>
doesn't really explain what you expect to happen when another HTTP
>
client, say Safari for example, contacts your server. Should Safari a)
>
download the file, b) download and unpack the file c) display the file
>
d) do something entirely different?
I don't plan to include the resource fork data for common file types
(jpeg, pdf, html, etc) unless the client asks for it (which mine will,
at least the Mac version). But if it were, say, a non-bundled
application or something, I would want Safari to decode the MacBinary
or AppleSingle or whatever and produce a regular Mac file; I think
that's what the user would expect.
>
HTTP is just a transport protocol. It doesn't say anything about the
>
semantics of the transported data. That would be done by HTML, XHTML,
>
MIME and other mechanisms. A Browser usually has built-in knowledge
>
that data sent with MIME-type (Content-Type) image/jpeg is a JPEG file
>
for example, or that application/x-stuffit is a stuffit archive that
>
can be decompressed using StuffIt Expander.
I'm assuming that most browsers will recognize "application/applefile"
or "application/x-macbinary". I'll have to do some testing and see what
happens.
--
David Catmull
email@hidden
http://www.uncommonplace.com/
[demime 0.98b removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
_______________________________________________
macnetworkprog mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/macnetworkprog
Do not post admin requests to the list. They will be ignored.