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.
........Roy
|