HTTP Gateway - by any other name?

I am concerned at the general thread of the discussion that says "since
CT proxies are actually gateways they can do what they like."

My reading of the HTTP spec, on which I am certainly willing to yield to
greater authority, is that the point of a gateway is that it acts as a
Server to the CLIENT, not that it acts like a client to the origin
server:

	A server which acts as an intermediary for some other server.
      Unlike a proxy, a gateway receives requests as if it were the
      origin server for the requested resource; the requesting client
      may not be aware that it is communicating with a gateway.

Like so much else in HTTP it does seem as though there is plenty of
wiggle room to read it as you please, but the examples given are those
of providing a Web view on email, news and so on. Not specifically
giving a Web view on the Web. 

In particular in the following:

14.23 Host

   The Host request-header field specifies the Internet host and port
   number of the resource being requested, as obtained from the original
   URI given by the user or referring resource (generally an HTTP URL,
   as described in section 3.2.2). The Host field value MUST represent
   the naming authority of the origin server or gateway given by the
   original URL. This allows the origin server or gateway to
   differentiate between internally-ambiguous URLs, such as the root "/"
   URL of a server for multiple host names on a single IP address.

I read this as saying that both the URI and the Host header refer to the
origin server and not the CT entity and hence it should not be regarded
as a Gateway, which from the point of view of the client is an end-point
in its own right.

There may be examples of Gateways, such as typing your URI into an
operator's portal, that then makes it appear that the resource is hosted
there, but that's not my understanding of what we are talking about in
the general case - where in general we are talking about an intermediary
device:

	which acts as both a server and a client
      for the purpose of making requests on behalf of other clients.
      Requests are serviced internally or by passing them on, with
      possible translation, to other servers. A proxy MUST implement
      both the client and server requirements of this specification. A
      "transparent proxy" is a proxy that does not modify the request or
      response beyond what is required for proxy authentication and
      identification. A "non-transparent proxy" is a proxy that modifies
      the request or response in order to provide some added service to
      the user agent, such as group annotation services, media type
      transformation, protocol reduction, or anonymity filtering.

So in general, I don't think that recasting this as "the proxy and the
original user agent together should be considered as a distributed user
agent" really clarifies anything, and I think is likely to be regarded
politically as "we are looking for a loophole that demonstrates that we
are entitled to do what we have been doing all along, and don't plan to
change it irrespective of the inconvenience is it causing".

That's a very harsh way of putting it and I don't think that it's an
accurate reflection, but I think we should be sensitive to possible
perceptions of the outcome of this work.

Jo

Received on Tuesday, 19 February 2008 12:59:45 UTC