Re: Updated proposal for OPTIONS issue

JM> (8) [For the moment, two possible alternatives here!]

  I'm afraid that I can't decipher whether it is (8a) or (8b) that I
  like or whether I don't like either one.  Simply stated, I would
  prefer that proxies never modify either Public or Allow headers;
  they should always be end-to-end headers.  I choose this alternative
  because I think it is easier for a client to discover what is going
  on this way.

  If proxies DO modify the Public and Allow headers, an end-client
  can't tell whether it is the origin server or the proxy that doesn't
  support what it wants because it sees the same response from both.
  While it is true that the client may have another way to reach the
  origin server, if that is not the case there will be no way for the
  user to determine that the proxy is the problem.  Since many users
  are behind proxies they cannot get around, there would be no way for
  them to discover that the reason they can't use some service is that
  the proxy is missing something.

  If proxies DO NOT modify Public and Allow headers, the methods
  supported by the origin server can be discovered by sending an
  OPTIONS request, and the methods supported by each proxy can be
  discovered by sending an OPTIONS request with a Max-Forwards
  header.

  This would be a slight change to RFC 2068 definition for the
  treatment of these headers by proxies, but as far as I can tell
  there are no deployed 2068 proxies out there yet, so I don't think
  that is a practical concern.  Even if there were, a client could
  detect that a proxy was 2068-only by sending OPTIONS with a
  Compliance header to the proxy and get back an OPTIONS response
  without a Compliance header.

--
Scott Lawrence           EmWeb Embedded Server       <lawrence@agranat.com>
Agranat Systems, Inc.        Engineering            http://www.agranat.com/

Received on Friday, 25 July 1997 06:55:50 UTC