httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexei Kosut <>
Subject Re: Negotiation updates, and transparent neg.
Date Tue, 20 Aug 1996 18:43:02 GMT
On Tue, 20 Aug 1996, Paul Sutton wrote:


> I also think that there should be a config option to turn transparent
> negotiation on or off on a per-dir basis, since it can affect the outcome
> of the negotiation, and there might be cases when the server should not
> trans neg, even if the client says it wants to. But I agree the should be
> ifdef'ed until the draft is approved (incidently it is an Internet Draft,
> since Aug 14....).

I know that. Not sure about the configurable part. My general feeling is
that except when it affects functionality or server
hardware/network/memory stuff (like keepalives and timeouts), the HTTP
protocol should be transparent from the user. 


> > How is this different than the normal accept header scenario? If I recall
> > correctly, a short accept header is simply a non-existant one, or "*/*".
> > Which is what Apache should default to anyway, since that's what the spec
> > says.
> I think the difference is that if you are using trans. neg (i.e.  the
> 'network algorithm') the meaning of a short header changes from 'all
> acceptable' to 'none acceptable'.  This forces a "List" (300) response.

Hmm. But since it's a */*, shouldn't it always form a list? Or has Koen
changed that again.

> > > The new code in mod_negotiation.c is fairly throughly commented.
> >
> > That alone proves that you're not cut out as an Apache developer :) BTW, I
> > discovered a new "interesting" comment in the code today; one I've never
> > seen before. In util.c: "robm=pinhead". Very informative.
> Argh, damn. I guess Apache comments should at least mention who owes beer
> to whom...

Or at the very least, grape soda.


> Yes, I thought about that, but than I thought that the process of creating
> a HTML text of the variants might be expensive. So I move the data to text
> conversion into the output stage, and stored the raw data where I would
> have stored the text... I guess that was a bad move!

Same difference, isn't it? You could just store the pointer to the data,
but anyhow. It's still cleaner having it all done in send_error_response.

> At the moment the variant list just prints out the bare filename,
> description, type, langauge and charset...  but it would be nice to output
> a really readable list, eg
>     info.en.html (HTML, English version)
> (HTML, French version)
> (Postscript, English version)
> (This would require some additional config directives, such as
> LanguageText en English, or maybe an option name on the AddLangauge
> directive, such as AddLanguage en en English. Although maybe the new
> "Description" item in the .var file is sufficient for now? Also I'm not
> too happy about returning text in english for the 406 and 300 status...
> this should be server configurable, e.g. VariantListHeader "<h1>Multiple
> Choices</h1>Please select a suitable variant from the list below", to
> allow text in other languages).

I wouldn't worry about it. Apache is all in English. Maybe we should
really move all the text that's sent over the wire to a .h file, as
defines, so it'd be easy to localize, but... *shrug*

> Okay, maybe I'm over estimating the time required to do this conversion.
> I'll fix it up to store text instead and remove the dodgy
> table_set_data().

It's not a bad function (though I'd call it table_setn or something), just
I don't think it's neccessary in this case.

-- Alexei Kosut <>            The Apache HTTP Server

View raw message