W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1997

Re: Negotiation comments

From: Koen Holtman <koen@win.tue.nl>
Date: Wed, 19 Feb 1997 21:59:39 +0100 (MET)
Message-Id: <199702192059.VAA25766@wsooti08.win.tue.nl>
To: Paul Sutton <paul@ukweb.com>
Cc: http-wg@cuckoo.hpl.hp.com
Paul Sutton:
>
>A few points about draft-ieft-http-negotiation-00 .... 
>
>1.  Section 8.2: the footnote should say "Accept-Charset" not
>    "Accept-Language"

Oops.  I'll fix it.

>2.  Presence of a Content-Location header on the end-point of a
>    negotiated resource is taken to indicate that the end-point
>    was itself negotiated (10.2 item 3). But in Content-Location is
>    defined in rfc2068 (14.15) as an optional header for any
>    response.

Yes, Klaus Weide noted that too.  I'll omit the check for Content-Location
in the next version.

>3.  rvsa-version is defined as number "." number, where number is
>    1*digit. This is unbounded in size, making processing difficult.
>    Could the size of the two numbers be limited (say to 3DIGIT)
>    similar to the HTTP-Version in rfc2068

It could, I'll change it.

>4.  10.3 says that in an ad hoc response "Content-Location" is never
>    valid. Ad hoc responses are effectively any old HTTP/1.1 response
>    with Alternates and Vary added. Denying Content-Location in
>    a standard response conflicts with rfc2068 (14.15) where
>    Content-Location is valid.

Well, the draft uses the presence of Content-Location to determine whether
the response is a choice response or an ad-hoc response.  This is why there
may be no Content-Location in an ad-hoc: if there was, it would be mistaken
for a choice response.  This limitation does really limit your ability to
use a content-location header: you can always make a choice response if you
want to have a content-location header.

>5.  12.1 para 1 says that if the UA cannot do transparent negotiation
>    the server MUST (my emphasis) only send ad-hoc, choice or list
>    responses, if the response is 2xx or 3xx (except 304). If I am
>    reading this correct it means that if a non-negotiating browser
>    requests a resource from a negotiating server, _even if_ that
>    resource is not negotiated or negotiated by a custom algorithm the
>    response must be ad-hoc, choice or list (rather than a response
>    compatible with rfc2068 alone).

You are either not reading it correct, or the sentence is too short.  If the
resource if not transparently negotiated, the server may of course do
whatever it wants.  What I meant was:

   When getting a request without a Negotiate header indicating support for
   transparent content negotiation *on a transparently
   negotiable resource*, the origin server may
   use a custom algorithm to select between sending a list, choice, or
   ad hoc response.

I'll put this text in the next version.

>    I don't understand the need for this paragraph.

We need this rule -- for transparently negotiated resources only -- because
an intermediate proxy which does understand TCN could get confused
otherwise.  It might think that the resource was changed to a
non-transparently negotiated one, and clear all kinds of cache entries.

>  Surely if the
>    server wants to it can choose to use a custom algorithm and return
>    a standard response, whether or not the UA can support tcn.

Yes.

>
>Paul

Thanks for your comments.

Koen.
Received on Wednesday, 19 February 1997 14:25:53 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:32:29 EDT