Re: Versioning HTML at the server and Accept-inline

[email protected]
Thu, 27 Oct 94 09:20:01 PDT

Marc VanHeyningen <[email protected]> writes:
>Chris Wilson writes:
>> Tony Sanders writes:
>> >Kee Hinckley writes:
>> >> o Accept-inline:
>> >No need. The browser should simply send the appropriate standard Accept:
>> >headers when it requests the inline data.
>>
>> Not true. Take, for example, the instance where I have an external viewer
>> for Targa images, but my browser can't handle them internally (or I don't
>> want it to, since Targa images tend to be large - perhaps I only want to
>> allow GIFs.)
>
>Yes, but your browser knows prior to making the request whether or not it
>intends to display the result inline or externally, and can generate
>different Accept: headers appropriately.
>
>(Conversely, if you use Accept-inline, how the heck is the server supposed
>to know whether you're fetching the given object as an inline or an external
>image?)

Ah, I see the apparent "hole" in my argument. I'm not saying that if I make
a request for "blah.gif", the server should know that I'm thinking that's an
inlined image. I'm saying that in the case where I make the request for
"blah", and I don't know what type the document is, if it's an image, the
server should pay attention to the "Accept:" headers. If it's an HTML
document, the server should look at the "Accept-inline:" headers to see if
it should send back the inlined images as well, via multipart MIME, etc.
I don't see any other way of telling the server "Send me back this document,
and if it has any component pieces, send them back too," while still
specifying which top-level types and which component (inline) types you
can handle.

-Chris Wilson

:::::::::::::::::::::<<< NETWORKING THE DESKTOP >>>::::::::::::::::::::
Chris Wilson Spry, Inc.
WWW Technology Lead 316 Occidental Avenue S. 2nd Floor
Email: [email protected] Seattle, WA 98104
Phone: (206) 447-0300 FAX: (206) 447-9008
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::