Re: Updated proposal for OPTIONS issue

I agree with Scott that Public and Allow should be end-to-end, but it
would be nice to hear from some client implementers on this issue...

** Reply to note from "Scott Lawrence" <lawrence@agranat.com> Fri, 25 Jul 1997 09:47:21 -0400
>   
>   
> 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/
>   
> 
 

Richard L. Gray
chocolate - the One True food group

Received on Tuesday, 29 July 1997 08:39:39 UTC