Re: Call for compatibility testers

On Thu, 8 Aug 1996, Roy T. Fielding wrote:

> > The transparent content negotiation draft
> > (http://gewis.win.tue.nl/~koen/conneg/) currently specifies the 300
> > response code for list responses.  
> > 
> > It turns out that this is not compatible with several existing
> > browsers: lynx and some versions of Mosaic fail to display anything if
> > they get back a 3xx class response without a Location header.  As lynx
> > in particular will be important for some people who want to offer
> > negotiated material, this rules out use of the 300 response code in
> > transparent content negotiation.

[...]

> And is out of the question.  Bugwards compatibility is achieved by
> looking at the User-Agent value, and sending 406 (or just 200 with
> an appropriate Vary and Alternates) is better than generating a
> success message masked as a client error.

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. According to version pre02-19 of the draft, support for
transparent negotiation is indicated by the presence of a Negotiate:
header. Presumably, any user agent that sent this header supports the
300 response code (to do otherwie would be the height of idiocy - not
to say that it might not happen, though).

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.

Why? I know the user agent can't parse the Alternates: header; even if
I sent a Location:, the user agent would just end up getting that
document anyway (and note that popular browsers like Netscape
Navigator do not do automatic redirection when they are given a 300
response code and a Location: header - they only do that for 301 and
302). Plus, I'd wager that the majority of negotiated content is (and
would be in the future) for inlined objects. And while if I'm
negotiating between text and postscript, it's acceptable to send an
HTML representation that asks the user to choose by clicking on a
link, if I'm negotiating between GIF and PNG, odds are it's an inline
request, in which case if I send HTML, the user agent will give the
user a broken image icon.

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 this principle is used, a user agent that does not support 300
reponses will never receive one; even via a proxy cache, if the server
(as recommended by the spec) sends "Vary: Negotiate", and an immediate
expires for HTTP/1.0 requests.

So, in short, I don't see the problem.

-- 
________________________________________________________________________
Alexei Kosut <akosut@nueva.pvt.k12.ca.us>      The Apache HTTP Server
URL: http://www.nueva.pvt.k12.ca.us/~akosut/   http://www.apache.org/

Received on Friday, 9 August 1996 15:25:18 UTC