Subject: [core] #20: Proxying clarification

From: "core issue tracker" <[email-masked]>
Date: Fri, 20 Aug 2010 13:04:53 -0000

#20: Proxying clarification
--------------------------------+-------------------------------------------
 Reporter:  zach@…              |       Owner:         
     Type:  enhancement         |      Status:  new    
 Priority:  major               |   Milestone:  coap-02
Component:  coap                |     Version:         
 Severity:  -                   |    Keywords:         
--------------------------------+-------------------------------------------
 The following changes with regard to Section 5.3. Proxying are proposed:

 - A new list item is required for the steps upon receiving a Uri-Authority
 header. In the case that this option is received by an end-point which
 does not support proxying, then an error is returned as specified in
 Section 2.5.1 since the option is critical.

 - The behaviour when a proxy receives a request with a Uri-Authority of
 the proxy itself should be clarified. It is proposed that the proxy
 returns a 400 Bad Request in this case.

 - The Uri-Scheme Option is not actually required in the current CoAP
 design, and this proposes that the option be removed for simplicity. A
 CoAP-CoAP proxy simply assumes that the scheme is coap:// and a CoAP-HTTP
 proxy assumes that the scheme is http://. This obviously means that a
 proxy on the same port can't support both CoAP-CoAP and CoAP-HTTP
 functionality (something people can surely live with) as it wouldn't know
 which to perform.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/20>
core <http://tools.ietf.org/core/>

---

From: "Edward Hill" <[email-masked]>
Date: Fri, 20 Aug 2010 11:43:05 -0400

>  returns a 400 Bad Request in this case.

Coap-01 says "If the authority (host and port) is the same as the proxy
end-point, then the request MUST be treated as a local request". Why
change this to return 400 Bad Request?

- Ed

---

From: Zach Shelby <[email-masked]>
Date: Mon, 23 Aug 2010 13:21:53 +0300

Ed,

> change this to return 400 Bad Request?

Right, this was the assumption so far. However, at interop it was pointed out (by Klaus if I remember right) that this behavior doesn't make much sense. A proxy is usually realized as a dedicated end-point, so treating this as a local request would really just mean it returns a 404. In this case though the Uri-Authority option was probably included by mistake in the request, so returning a 400 would be a clearer error.

Does anyone else see the need for changing that to a 400? If not, then I am happy to leave the behavior as it is in coap-01.

Zach

> 
> - Ed
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 23 Aug 2010 12:31:57 +0200

On Aug 23, 2010, at 12:21, Zach Shelby wrote:

> Does anyone else see the need for changing that

I think we need to be clear whether a request to a server should include the authority or not.
Not all servers (if very constrained) may be able to find out whether an authority given is actually themselves or not.  Instead of getting simple hosts into the habit of accepting any authority, I think it would be better to leave the onus to connect to the right place to the client.

(The underlying question is how important the virtual server concept is.  If we expect virtual servers to be an important feature, we'll need to have the authority in there always, just as HTTP always has a Host: header.  If we ask clients to leave out the authority, we can't have virtual servers.  We can't have the client make a decision whether the server will be using virtual servers.  The above paragraph assumes not sending the authority is more important than having the virtual server capability.)

Gruesse, Carsten

---

From: Peter Bigot <[email-masked]>
Date: Mon, 23 Aug 2010 08:56:08 -0500

How does a client determine whether it must include the authority in a
request to a server (i.e., server is a proxy), or must not include it
(i.e., server is the origin server)?

Peter

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 23 Aug 2010 16:34:04 +0200

> (i.e., server is the origin server)?

If the client is configured to use a server as a proxy, it sends a request with an option giving the authority of the origin server to the proxy.
If the client is not so configured, it sends a request without the authority option to the server.

(In other words, as with HTTP, the decision to use a proxy is orthogonal to the URI.)

(All this is assuming that we stick with the model I was proposing, which does not allow virtual servers.  I think we need to decide this at some point.)

Gruesse, Carsten

---

From: Peter Bigot <[email-masked]>
Date: Mon, 23 Aug 2010 10:18:54 -0500

OK.  I wasn't thinking of proxy as a client-configuration choice as in
the browser sense, but in a more transparent caching sense where some
servers can't always be directly reached by the client so pass through
an intermediary that deals with things like sleeping nodes.  For
example, I'd planned to run a CoAP server on my gateway, which would
serve as a proxy to allow wired clients to connect to nodes in the
wireless network.  I guess that does require a virtual-server model.

Absence of the URI authority in requests to the gateway will be
inconvenient, since I'll have to map the actual destination host
somewhere in the URI path, strip it out when the request is forwarded,
and put it back when sending the response to the client.  So the same
resource is accessed by different URIs depending on whether it's a
direct connect or has to pass through an intermediary, and I can't
hide that at the service interface level by doing DNS tricks.

This might make an HTTP bridge more complicated.

Peter

---

From: Zach Shelby <[email-masked]>
Date: Tue, 24 Aug 2010 15:03:42 +0300

> (In other words, as with HTTP, the decision to use a proxy is orthogonal to the URI.)

This is how I have assumed this works. We have also this model implemented and tested, no problems so far.

Note that Brian Franck has also given some thought to transparent proxying, which is what Peter had in mind. For now we decided not to discuss that in the draft. In practice though, transparent proxying should not require any special consideration in the protocol, nor does it need the Uri-Authority, as it is done using packet capture techniques. Do we need to mention this in the draft?

> (All this is assuming that we stick with the model I was proposing, which does not allow virtual servers.  I think we need to decide this at some point.)

I would prefer not to support virtual servers. 

Zach

---

From: Peter Bigot <[email-masked]>
Date: Tue, 24 Aug 2010 09:17:40 -0500

Could we have a ticket to discuss this separately?

Peter