Mailing List Archive

content negotiation
Robert, would it be possible to extend your system to take other
HTTP fields into account, e.g. Accept-language: and User-agent: ?

One possibility is to name the map file according to the header being
considered, eg.

map.accept
map.user_agent

?

or even

map.accept.2
map.accept_language.0
map.user_agent.1


To force the User-agent mapping to be considered before Accept:, but
after Accept-Language:



robh
Re: content negotiation [ In reply to ]
From: Rob Hartill <hartill@ooo.lanl.gov>
Date: Wed, 15 Mar 95 11:17:37 MST

Robert, would it be possible to extend your system to take other
HTTP fields into account, e.g. Accept-language: and User-agent: ?

One thing I'd considered was an extended map file format of the form:

foo.mozhtml: {
Content-type: text/html; level = 3; q = 0.9
User-agent: Mozilla
Force-some-header: this-goes-to-clients-if-not-recognized-by-server
}

foo.html3: {
Content-type: text/html; level = 3; q = 0.8
Force-some-header: this-goes-to-clients
}

foo.html: Content-type: text/html; level = 2; q = 0.5

where mismatches on User-agent, Language, or whatever would exclude a
file from consideration, and arbitration among whatever was left would
be broken by combined quality value, breaking ties among q*qs by order
of Accept: line from the server. (The reason for this is to do
something sensible with browsers which don't send *any* q values, but
seem to list the MIME types they Accept: in rough priority order ---
Mosaic 2.5 for one; you can easily override it by setting server
quality ratings in the map file).

NB I'm not sure whether the right thing for language is to handle it
as a separate header in the extended format, or simply to have it as a
lang= parameter in the mapped MIME types; the answer is presumably in
the MIME RFCs. Roy, any thoughts?

(In any case, it would be good for languages to be supported for
MultiViews as well, as in the equivalent feature in the CERN server).

Unresolved issues here are how to specify matches to the User-agent:
header (initial substrings to match? Full regex's --- and using whose
library if so? Something else?)



NB, I could code this fairly quickly. I did the first pass of this
stuff in a spurt that lasted from 10:00 AM to 10:00 PM --- twelve
hours, counting the hour or I so spent at the Boston ICA viewing their
exhibit of artists' reflections on the Holocaust. It is just NOT all
that hard. However, one effect of all the "Go slow! Go slow!" talk
has been to make me try to limit the scope of my own efforts, in the
hopes of getting them into something that stands a chance of getting
out.




(FWIW, I just got mail from some guy in another department at MIT who
I had not introduced to this list or to the project, who I have never
met, and who I have never even *heard* of, saying how he'd been over
to hyperreal, and how great apache-pre looks.

I don't think it looks great. I don't think the process that gave
rise to it is the way we should be building releases. I want it to
serve its purpose and DIE. However, it's there and it more or less
works; if we don't produce something better with all deliberate speed,
there is the risk that it will take on a life of its own).

rst
Re: content negotiation [ In reply to ]
rst writes:

> NB I'm not sure whether the right thing for language is to handle it
> as a separate header in the extended format, or simply to have it as a
> lang= parameter in the mapped MIME types; the answer is presumably in
> the MIME RFCs. Roy, any thoughts?

It's in the latest HTTP/1.0 spec -- Accept-Language and Content-Language.
The only thing that appears in a Content-type is a ;vary="lang" if
variants exist at that URL with different Content-Language values.

> Unresolved issues here are how to specify matches to the User-agent:
> header (initial substrings to match? Full regex's --- and using whose
> library if so? Something else?)

That is a nontrivial problem and generally only handled within scripts.
I would avoid it like the plague (for now).

......Roy