httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Sutton <p...@ukweb.com>
Subject Re: Negotiation updates, and transparent neg.
Date Tue, 20 Aug 1996 07:14:27 GMT
On Mon, 19 Aug 1996, Alexei Kosut wrote:
> I would perfer that Apache not implement, out-of-the-box, a spec that is
> in flux as much as the Holtman one is. #ifdef-ing out the part where it
> checks to see if a Negotiate: header is present would be best, unless we
> can get the http-wg to decide that either the draft will stay as is
> substantially (but since it's not even currently a wg draft...) or
> convince the http-wg and Koen to change the header name if it changes
> (more likely). Roy is probably the person to ask about this.

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

> >    1. Transparent negotiation _only_ enabled if Negotiate:
> >       header received
>
> Good. As much as Koen likes to tell us otherwise, I cannot imagine a
> scenario where sending a 300 response to a non-transparent
> negotiation-supporting user agent would be useful, especially since some
> of them crash.

Yeah, as far as I'm concerned the server should never trans neg unless the
client says it can handle it.  But, it might be nice if Apache could be
configured to give the equivalent of a 300 response in some cases, but
with a 200 status. So, a if you request a Multiviews directory, or request
a .var file, you'd get the formatted list of variants, instead of the best
matching variant or a 406.  This is exactly equivalent to requesting a
directory and getting a list of files... which returns a 200 status.

> >    2. Implements 'short accept header' response
>
> 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.

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

> > be too general. Perhaps there is a simple way to do this that I am
> > missing?
>
> Yes. There is. Have mod_neg generate an HTML list. Put it into r->notes
> under a key of "variants" or some such. Have the 300 and 406 handlers in
> send_error_response() check for such a note, and if it exists, output the
> contents. Easy. This is similar to a callback, but gracefully decomposes
> if mod_negotiation is not compiled in, or if some other module also sends
> a 300/406. I consider it to be a perfectly acceptable solution otherwise,
> and was how I was planning to implement list responses.

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!

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)
    info.fr.html (HTML, French version)
    info.en.ps (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).

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().

Paul
--
Paul Sutton, Technical Director, UK Web --- http://www.ukweb.com/~paul/
Apache Week: Latest news on Apache server... http://www.apacheweek.com/


Mime
View raw message