- From: Scott Lawrence <lawrence@agranat.com>
- Date: Wed, 23 Jul 1997 09:59:01 -0400
- To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
I like the revised proposal better, and I think that it does as well
as can be done to preserve compatibility with 2068 implementations,
and I very much like the idea of using RFC numbers as feature
identifiers.
On the question of proxies modifying the responses, perhaps it would
be better for a proxy that does not implement a particular feature
to add a non-compliance indication without removing the original
assertion; this might enable a client to detect the true situation.
Non-Compliance =
"Non-Compliance" ":" proxy-host 1#non-compliance-option
proxy-host = host [ ":" port ]
non-compliance-option =
compliance-namespace "=" option-item [ ";" option-disposition ]
option-disposition = "passed" | "dropped"
If the proxy recognizes the option-item as one that it will pass
through but not react to, it will send the 'passed'
option-disposition. If it recognizes the option-item as one that
will not operate correctly through itself (either due to an
implementation restriction or as a matter of policy), then it will
send the 'dropped' option-disposition. If the proxy does not
recognize the option-item, it will send no option-disposition, in
which case the client must rely on its own knowlege of that item to
make any guess as to whether or not it might work through that
proxy.
A Non-Compliance header field MUST NOT be sent by any origin
server.
What do the client and proxy authors out there think? Would this
enable you to do something useful? Is there a way we could or
should modify the rules for the Public header like this?
--
Scott Lawrence EmWeb Embedded Server <lawrence@agranat.com>
Agranat Systems, Inc. Engineering http://www.agranat.com/
Received on Wednesday, 23 July 1997 07:09:17 UTC