httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <field...@avron.ICS.UCI.EDU>
Subject Re: content-arbitration
Date Sat, 08 Apr 1995 02:26:59 GMT
finally catching up on some old mail ...

rst said:

> (Incidentally, I don't think per-directory type maps are a bad idea,
> but the current type-map syntax doesn't easily generalize that far;
> there's nothing in it which says which entries are variants for which
> URIs.  I suppose Roy will point out that this is an advantage of
> hierarchical lisp-based syntaxes...).

Ummmm, hierarchical yes, but I personally hate Lisp.  PRDM (lisp-based)
is tolerable only because it is class-based and explicitly typed.
Actually, any hierarchical format that is trivial to parse (and readable)
would be good.  You are welcome to invent one.

>    I also find myself wanting to do:
>    URI: *.jpg
>    Content-type: image/jpeg; qs=0.8
>    URI: *.gif
>    Content-type: image/gif; qs=0.5
> Try this:
>   AddType image/jpeg;qs=0.8 jpeg
>   AddType image/gif;qs=0.5 gif

Grrr..grumble..grumble.  That's not what qs means -- how is the server
supposed to know which one is a "better source" on a global basis?
If the image has > 256 colors, a JPEG will clearly be better.  On the
other hand, a 255 color GIF will be a better source than a JPEG reduction
to 50 colors.

Also, at least one URI should have a qs of 1 -- the quality factor
is a degradation measure.  Gee, I guess that should be in the spec. ;-)

> However, with the current crop of browsers (which don't send q
> values), this will *always* send the jpeg if both are available, even
> if the browser actually said "Accept: image/gif" and didn't say
> anything at all about Accept:ing jpeg's.
> (This is the same problem you had earlier with html vs. html3; at
> least in that case, and for browsers which, unlike Netscape, send
> "Accept: text/html", things would work more sensibly if the 'q' values
> on wildcard Accept: headers defaulted to a value lower than one, say
> 0.1.  I could easily change the code to do this, but we then wouldn't
> be in conformance with the draft standard.  There are two ways out of
> this --- change the draft, or put it under control of a config
> directive, so people who want exact standard conformance can have it).

I will change the draft -- this is one of the issues I brought up at
the IETF.  Is it sufficient to say:

    Media ranges can be overridden by more specific media ranges or
    specific media types.  If more than one media range applies to
    a given type, the most specific reference has precedence.  For example,

       Accept: text/*, text/html, text/html;version=2.0, */*

    have the following precedence:

       1) text/html;version=2.0
       2) text/html
       3) text/*
       4) */*

    The quality value associated with a given type is determined by
    finding the media range with the highest precedence which matches
    that type.  For example,

       Accept: text/*;q=0.3, text/html;q=0.7, text/html;version=2.0, */*;q=0.5

    would cause the following values to be associated:

       text/html;version=2.0        1
       text/html                    0.7
       text/plain                   0.3
       image/jpeg                   0.5
       text/html;level=3            0.7

I think that will suffice.  I suggested letting */* default to q=0.5
at the meeting, but that didn't go over well.  I will also add some verbage
to the effect that a server may make type-specific assumptions about
parameter value precedence and inclusiveness (i.e., level=3 => version=3.0
and version=3.0 includes version=2.0 for text/html).

   NOTE: The level parameter is destined for extinction -- version will
         likely be used instead.  text/html with tables will probably be
         called "text/html;version=2.1"
         once the WG folks issue the new table draft and Dan Connolly
         updates his W3C stuff.

Another issue: We (as in the IETF) will not specify an automatable response
entity for codes 300 and 406 in HTTP/1.0 -- they will be treated like
any other error code, with the content determined by the server.
This will probably make more sense when the next draft comes out.


View raw message