Re: [core] Call for reviews of draft-castellani-core-http-mapping

[Carsten Bormann <[e-mail]>]

On Mar 26, 2013, at 15:52, Floris Van den Abeele <[e-mail]> wrote:

> Can the authors (or someone else) give clear examples of forward and reverse http/coap cross protocol proxies?

core-coap-14 defines:


   Forward-Proxy
      A "forward-proxy" is an endpoint selected by a client, usually via
      local configuration rules, to perform requests on behalf of the
      client, doing any necessary translations.  Some translations are
      minimal, such as for proxy requests for "coap" URIs, whereas other
      requests might require translation to and from entirely different
      application-layer protocols.

   Reverse-Proxy
      A "reverse-proxy" is an endpoint that stands in for one or more
      other server(s) and satisfies requests on behalf of these, doing
      any necessary translations.  Unlike a forward-proxy, the client
      may not be aware that it is communicating with a reverse-proxy; a
      reverse-proxy receives requests as if it was the origin server for
      the target resource.

... and goes on (5.7):

   In an overall architecture for a Constrained RESTful Environment,
   proxies can serve quite different purposes.  Proxies can be
   explicitly selected by clients, a role that we term "forward-proxy".
   Proxies can also be inserted to stand in for origin servers, a role
   that we term "reverse-proxy".  Orthogonal to this distinction, a
   proxy can map from a CoAP request to a CoAP request (CoAP-to-CoAP
   proxy) or translate from or to a different protocol ("cross-proxy").
   Full definitions of these terms are provided in Section 1.2.

   Notes:  The terminology in this specification has been selected to be
      culturally compatible with the terminology used in the wider Web
      application environments, without necessarily matching it in every
      detail (which may not even be relevant to Constrained RESTful
      Environments).  Not too much semantics should be ascribed to the
      components of the terms (such as "forward", "reverse", or
      "cross").

      HTTP proxies, besides acting as HTTP proxies, often offer a
      transport protocol proxying function ("CONNECT") to enable end-to-
      end transport layer security through the proxy.  No such function
      is defined for CoAP-to-CoAP proxies in this specification, as
      forwarding of UDP packets is unlikely to be of much value in
      Constrained RESTful environments.  See also Section 10.2.7 for the
      cross-proxy case.


So the point is that a client always knows when it is using a Forward-Proxy, i.e., it has explicitly chosen to talk to it as opposed to the origin server.  We have the options Proxy-Uri and Proxy-Scheme that enable to express this choice explicitly:

5.7.2.  Forward-Proxies

   CoAP distinguishes between requests made (as if) to an origin server
   and a request made through a forward-proxy.  CoAP requests to a
   forward-proxy are made as normal Confirmable or Non-confirmable
   requests to the forward-proxy endpoint, but specify the request URI
   in a different way: The request URI in a proxy request is specified
   as a string in the Proxy-Uri Option (see Section 5.10.2), while the
   request URI in a request to an origin server is split into the Uri-
   Host, Uri-Port, Uri-Path and Uri-Query Options (see Section 5.10.1);
   alternatively the URI in a proxy request can be assembled from a
   Proxy-Scheme option and the split options mentioned.

There is no way in a URI to specify the use of a forward-proxy.
Which forward-proxy is used is decided by the client based on local information (which may include information gleaned from the URI, of course).  The URI continues to looks

For a reverse-proxy, the client might be thinking it is talking to the actual origin server:
The URI directly points to the reverse-proxy, but instead of serving its resource directly, the reverse-proxy defers to an origin server (or another reverse proxy!).

5.7.3.  Reverse-Proxies

   Reverse-proxies do not make use of the Proxy-Uri or Proxy-Scheme
   options, but need to determine the destination (next hop) of a
   request from information in the request and information in their
   configuration.  E.g., a reverse-proxy might offer various resources
   the existence of which it has learned through resource discovery as
   if they were its own resources.  The reverse-proxy is free to build a
   namespace for the URIs that identify these resources.  A reverse-
   proxy may also build a namespace that gives the client more control
   over where the request goes, e.g. by embedding host identifiers and
   port numbers into the URI path of the resources offered.

draft-castellani-core-http-mapping-07.txt also alludes to the fact that there may be "transparent" (intercepting) entities intervening on the path to the origin server and acting a bit like reverse-proxies, except that the network provider has chosen to interpose them as opposed to the client.

Of course, all these types can be combined on a path to an origin server: A client can use a forward-proxy to talk to a reverse-proxy, with any number of additional reverse-proxies (and "transparent" (intercepting) proxies) on the way to the origin server.

Maybe draft-castellani-core-http-mapping-07.txt doesn't really need to define the terms forward-proxy and reverse-proxy, but can reference them from the core coap spec.  "transparent"/intercepting proxies are not discussed in core-coap, though.

Grüße, Carsten