httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christoph Schneegans <>
Subject qs values in conjunction with MultiViews
Date Wed, 13 Feb 2002 18:44:06 GMT

<> explains how to
use qs parameters in a type map file to assign a source quality to the
different variants. It does not explain how to use qs values in
conjunction with MultiViews, and
<> and
<> complain that there's no way
to set these values.

However, it seems to be possible, using the AddType directive:

  AddType image/svg;qs=0.85 svg svgz
  AddType image/png;qs=0.7 png
  AddType image/jpeg;qs=0.8 jpg jpeg

This works as expected but I'm concerned about the Content-Type headers
that are transmitted to the client:

  Content-Type: image/svg;qs=0.85
  Content-Type: image/png;qs=0.7
  Content-Type: image/jpeg;qs=0.8

In contrast to negotiation via type map, the qs values are included in
the response header.

<> says:

| The source quality is assumed to be 1.000 for all files (this can
| actually be set on the mime type, like "text/html;qs=0.5" but this
| confuses most browsers so is probably best not used).

I've tested with several browsers -- Opera 3.61, 5.12 and 6.01, Mozilla
0.9.8, links, lynx, IE6, Netscape 3.0.4 and 4.78, Amaya 4.3.2 and 5.3
don't complain. Does anybody know if there's a browser that can't handle
qs values?

The next question is if qs values are formally allowed in the
Content-Type header. According to RFC 2616, I think they are not, so
Apache should remove them. Or is this just an undesired side effect of
type map negotiation, i.e. are qs values not designed to work with
MultiViews? Any comments are greatly appreciated.

Best regards,
Christoph Schneegans


The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:> for more info.
To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message