Re: Call for compatibility testers

Alexei Kosut:
>
>Okay... let me ask a silly question. Having read the various versions
>of Koen's content negotiation drafts, I am at a loss to understand why
>a server would send a 300 response to a user agent that did not
>support it. 

You would send a list response to a user agent not supporting
transparent content negotiation if you want the user to manually pick
the best variant.

An example would be if you have a 5 minute movie in 3 different file
formats, or an executable for 5 different platforms.  

Basically, whenever you put a `click here for the X version, click
here for the Y version' list on a html page now, you will want to send
a list response to un-negotiating clients (which might not support
300) in future.  So these must be a way to send a list response
without using the 300 code.

Of course, for things like inline images, you would never send a list
response, you just send a choice response with a .gif of something.

[...]
>If I was writing a server to implement transparent negotiation, I
>would only send a 300 response if the user agent sent
>Negotiate:. Otherwise, I would make the choice on behalf of the user
>agent (based on the Accept: headers or some other indication), and
>send that document.

My point is that you do not always want to make a choice.  But you do
want to get rid if the `click here for the X version, click here for
the Y version' stuff on your main pages.

[...]
>All of this combines to convince me that the intentions of the spec
>(although it may not be explicitly stated - though it should be) are
>that unless the Negotiate: header is sent, the server should never
>send a 300 response, but should choose on behalf of the user agent,
>and send the chosen resource.

If no Negotiate: is sent, choosing on behalf on the user agent will
indeed be the normal case.

But the spec does recognize that there are situations in which you do
not want to return a list response, or have the proxy return a cached
list response on your behalf. (I don't know if the spec is explicit
enough about this: you can see it in section 11.2, but that is a
little late in the spec.)

By the way, I put mechanisms in the spec for letting proxies deal with
non-negotiating user agents, (like the min-q and forward attributes,
see Section 11.5.1), but I don't know if they do everything people
would want.  This is one area that needs careful review, in particular
by people who use server-driven negotiation now.  My own experience in
this area is limited.

One thing is sure though: no mechanism for letting proxies deal with
non-negotiating user agents can be perfect, because you basically
revert to Accept header based server-driven negotiation, with all the
problems of not getting enough information in the Accept headers.

>Alexei Kosut <akosut@nueva.pvt.k12.ca.us>      The Apache HTTP Server

Koen.

Received on Friday, 9 August 1996 06:03:19 UTC