Received: by taz.hyperreal.com (8.7.5/V2.0) id BAA27147; Tue, 20 Aug 1996 01:22:46 -0700 (PDT) Received: from gate.ukweb.com by taz.hyperreal.com (8.7.5/V2.0) with ESMTP id BAA27142; Tue, 20 Aug 1996 01:22:42 -0700 (PDT) Received: from star(really [192.168.2.10]) by gate.ukweb.com via rsmtp with smtp id for ; Tue, 20 Aug 96 09:22:37 +0100 (BST) (/\##/\ Smail3.1.30.13 #30.13 built 31-aug-95) Date: Tue, 20 Aug 1996 08:14:27 +0100 (BST) From: Paul Sutton X-Sender: paul@star To: new-httpd@hyperreal.com Subject: Re: Negotiation updates, and transparent neg. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-new-httpd@apache.org Precedence: bulk Reply-To: new-httpd@hyperreal.com 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 "

Multiple Choices

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/