Re: Accept: header

Eric Prud'hommeaux a écrit :
> 
> On Sat, May 12, 2001 at 09:23:21PM -0400, Eric Prud'hommeaux wrote:
> > On Sat, May 12, 2001 at 04:42:09PM -0700, Brendan Eich wrote:
> > > Gervase Markham wrote:
> > >
> > > > Brendan Eich wrote:
> > > > > > Does anyone object to this course of action? It goes without saying that
> > > > > > this pref would have _no_ user UI.
> > > > >
> > > > > I have no problem with it; I also have no problem with a short default pref
> > > > > that's better than */*.  I do not like the image/{png,jpeg,gif} proposal you
> > > > > quote above (what about mng?  what about next year's model for which inline
> > > > > image decoders can be field upgraded?).  Would it work to do
> > > > > image/gif;q=0.9, image/*;q=1 ?
> > > >
> > > > The current proposal is current because it was the only sensible
> > > > suggestion made in the bug. Now is as good a time as any for other
> > > > suggestions :-) My reading of the RFC suggests image/gif;q=0.9, image/*
> > > > would work.
> > > >
> > > > However, saying that all image types are equally acceptable causes
> > > > forward-compatibility problems - if a new image type arrives that
> > > > Mozilla doesn't support, it will be sent in preference to GIF, which it
> > > > does, and possibly in preference to JPG and PNG because they are all of
> > > > equal precedence.
> > >
> > > (Death to GIFs!  Let them eat PNGs. :-)
> > >
> > > I suppose we could enumerate known image types as you propose (but did you leave
> > > out image/mng, or is that covered by png?), and keep going (it's not as if new
> > > types emerge that frequently).  Something about it rubs me the wrong way.  More
> > > when I figure out what that is.
> 
> Sorry if I'm covering old ground here, but it seems like you're
> dividing between saying:
>   "I like all currently supported media types better than GIF."
> or:
>   "I like everything, including unsupported media types, better than
>    GIF."
> You can say the latter with
>   image/gif;q=0.9, image/*;q=1
> but the former requires possibly lengthly enumeration. I caution
> against the latter as it does not express the actuall preferences
> and therefor encourages ugly heuristics like user agent sniffing.
> Of course, one can always not express a preference at all and count
> on the server preferring to serve png over gif. That's
>   AddType image/svg;qs=0.85                             svg svgz
>   AddType image/png;qs=0.7                              png
>   AddType image/jpeg;qs=0.8                             jpg jpeg
>   AddType image/gif;qs=0.5                              gif
> in apache-speak, but that isn't distributed in the default conf so
> i doubt it's widely deployed.
> 
> I don't see a good way around enumeration without getting everyone in
> the world to agree on and implement (simultaneously) some sane subsets
> of the media types with macro identifiers like
> application/image-set-1.
> 
> A more terse protocol could leverage off the existence of the registry
> and use a bit position to identify a media type (something like 6E;q=1
> implies jpeg,png,svg,tiff,jiff at q=1) but hey, that's not the world
> we live in.

It may be that this is the world we *could* live in when folks implement
CC/PP - you could have a URI that points to a particular combination of
images, and even call it http://www.example.org/6E;q=1, I guess. Behind
this URI would be a CC/PP description, but you don't have to get that if
you hard-code the semantics of the URI into your browser.

More on CC/PP:
http://www.w3.org/TR/CCPP-struct-vocab/
http://www.w3.org/TR/CCPP-ra/
http://www.w3.org/TR/NOTE-CCPPexchange
http://www1.wapforum.org/tech/documents/SPEC-UAProf-19991110.pdf
http://www.w3.org/Mobile/CCPP/

Received on Sunday, 13 May 2001 04:27:43 UTC