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

["Dijk, Esko" <[e-mail]>]

Hi Klaus,

> - 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.

If I apply the same argumentation, I may get these 2 cases:

1) The client has a coap:// URI and makes the unilateral decision to perform an HTTP request (with the coap:// URI translated to a http:// URI according to some standardized scheme) to the proxy. Then the proxy makes the decision to get the coap:// URI out of the HTTP request and performs a CoAP request using this coap:// URI.
-> Forward proxy.

2) The client got a http:// URI from someone, doesn't know a thing about CoAP, and this URI happens to be the same http:// URI as the one in point 1) above. Then the HTTP server makes the unilateral decision to get the coap:// URI out of the HTTP request and performs a CoAP request using this coap:// URI.
-> Reverse proxy.

The point/issue here is that the proxy acting in point 1) and 2) is the same HTTP server operating in exactly the same way. And it's both a Forward and a Reverse proxy depending on what the client knows. So it's hard to define guidelines for a Reverse Proxy only, because it could unknowingly be also a Forward Proxy. Therefore I argued that the distinction in this way is not useful.
(See also the earlier thread http://www.ietf.org/mail-archive/web/core/current/msg04170.html )

Esko

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Klaus Hartke
Sent: Thursday, April 11, 2013 21:46
To: [e-mail]
Subject: Re: [core] Call for reviews of draft-castellani-core-http-mapping

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
_______________________________________________
core mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/core

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.