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 Mon, 19 Aug 1996 17:58:40 GMT
On Mon, 19 Aug 1996, Paul Sutton wrote:

> In some mail I sent a couple of weeks ago I noted that Apache doesn't
> do content negotiation fully according to HTTP/1.1.  For example, it
> doesn't handle any Charset negotiation, or 'q' values on
> Accept-Language lines. I've made some changes to implement these.

Darn... and here I was hoping I was going to be forced to do it... Thanks

> While doing this, I thought it would be useful to update the code so
> that it can handler additional negotiation algorithms, in particular,
> to allow implementation of transparent negotiation. I did this, then
> actually implemented to negotiation from the Holtman draft.  Even if
> this gets changed around a lot in the future, the code can now easily
> accept new negotiation algorithms and customisations. I've implemented
> most of the Holtman draft except for (a) cache control stuff and (b)
> features (which are vaguely defined). Note that the Holtman stuff does
> not affect existing functionality unless the browser sends a
> Negotiate: header.

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.

>   * Updates Apache to properly support HTTP/1.1 server-driven
>     negotiation
>   * Updates Apache to support most of the Holtman draft
> I've FTP'ed it to hyperreal, in /httpd/incoming/mod_negotiation.patch

I've done a cusory examination of the patch, and for the most part, it
looks good. I hold back further judgement for a more comprehensive look
at the code and its behavior.

>    1. Accept-Language negotiated correctly using 'q' values
>       (also now matches on language prefix, and handles '*')
>    2. Accept-Charset negotation done
>    3. Accept-Encoding updated to never send unacceptable encodings
>    4. After a 406 error status, the body will include a HTML
>       list of variants
>    5. Sets Vary: to just the headers negotiated on

It does this already. Therefore it can't be a change. :)

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

>    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

>    3. Implements the Network Algorithm
>    4. Implements "List" (300) and "Choice" responses
>    5. For "List" 300 responses, outputs variants as HTML list
>    6. Updated Vary: header (including 'negotiate' tag)
>    7. Generates "Alternates:" header where appropriate
>    8. Sets Variant-Vary, Content-Location as appropriate
>    9. Adds error code 506 Variant Also Varies status
> Patch Details
> -------------
> The patch modifies five files:
>    http_protocol.c/
>             httpd.h  -- adds 506 error status
>    alloc.c/alloc.h   -- adds table_set_data() func to set a table
>                         entry whose value is not a string

This sounds like a bad idea. See below. (if you need to use non-char data,
you should make up your own array, and not use tables).

>    mod_negotiation.c -- all the rest
> Implementation Notes
> --------------------
> 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.

> The biggest problem implementing this was getting the functionality
> where a 300 or 406 error status output a list of variants in the
> body. Normally, the module would return the appropriate status (300 or
> 406) which the called (process_request_internal or whatever) could
> then pass on to the error response routine. The problem is, how does
> the error handler get at the variant information? One way would be a
> callback to the module, keyed on error status code...  but that might
> 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.


-- Alexei Kosut <>            The Apache HTTP Server

View raw message