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

[Klaus Hartke <[e-mail]>]

Esko Dijk wrote:
> I propose to define the forward/reverse proxy in such a way that the "client awareness" does not play a role anymore

Client awareness is pretty much what distinguishes a forward proxy
from a reverse proxy.


Assume a client retrieves a representation of a resource and this
representation contains a link. Then there are the following cases:

* The client uses the information in the URI to connect to a server.
The server at that address is the authoritative source for
representations of the resource identified by the URI, so it returns a
response directly.

     -> "Origin server".

* The client uses the information in the URI to connect to a server.
However, the server is _not_ the authoritative source for
representations of the resource identified by the URI. Instead, it has
been configured to obtain the representation from an unrelated third
party. Which third party it connects to can come from local
configuration or be embedded in the URI. From the perspective of the
client, the response looks and feels exactly as a response from an
origin server, though.

     -> "Reverse proxy". It is an unilateral decision of the server to
obtain the representation from a third party.

* The client does _not_ use the information in the URI. Instead, it
has been configured to connect to an unrelated third party. The client
requests this third party to obtain the representation of the resource
identified by the URI, well aware that this third party not the
authoritative source for the representation.

     -> "Forward proxy". It is an unilateral decision of the client to
request a third party to obtain the representation and not to connect
to the server specified in the URI.


The protocol between client--proxy and proxy--origin-server do not
have to be the same. For example, a client can make an HTTP request to
a reverse proxy and the reverse proxy makes a CoAP request to the
origin server.

http://coap.me/ is a good example of an HTTP/CoAP cross-protocol
reverse proxy. It embeds the information which CoAP server to connect
to in the http:// URI, and rewrites all links in representations
obtained from CoAP servers to http:// URIs, so you can use a simple
web browser to browse CoAP servers.

The protocol between client--forward-proxy is often a bit different
than between client--origin-server and client--reverse-proxy. For
example, when a client makes a CoAP request to a forward proxy, the
URI is transmitted in the Proxy-Uri Option and not in the Uri-*
Options. Similarly, when a client makes an HTTP request to a forward
proxy, the entire URI is transmitted in the request line and not in
the Host header field.

Unfortunately, in case of a HTTP/CoAP cross-protocol forward proxy, we
cannot simply put a coap:// URI in the HTTP request line. So we need a
different protocol that both the client and the forward-proxy agree on
to encode this request. One way is to let the client translate the
coap:// URI to an http:// URI in a standardized way, and the forward
proxy translates the http:// URI back to the original coap:// URI.


The line between reverse proxy and forward proxy seems to blur when we
embed coap:// URIs in http:// URIs in the reverse proxy case, and
translate coap:// URIs to http:// URIs in the forward proxy case. But
it doesn't.

- Does the client have an http:// URI and does the HTTP server make
the unilateral decision to make a CoAP request (based on an embedded
coap:// URI in the http:// URI, opaque to the client)? Reverse proxy.

- Does the client have a coap:// URI and does it make the unilateral
decision to perform an HTTP request (with the coap:// URI translated
to a http:// URI according to some standardized scheme)? Forward
proxy.


Just my 2 cents.

Klaus