Opened 12 years ago

Closed 12 years ago

#23 closed protocol defect (fixed)

Virtual server capability?

Reported by: zach@… Owned by: zach@…
Priority: minor Milestone: coap-02
Component: coap Version:
Severity: - Keywords:


Carsten pointed out that we need to decide whether to support the Uri-Authority option in non-proxy requests (and thus the virtual server concept). From the original mail:

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

Change History (2)

comment:1 Changed 12 years ago by zach@…

From a longish WG list discussion led by Peter Bigot it became clear there is a valid use case for the URI Authority in CoRE. However, for efficiency it should be possible for a client to leave the URI-Authority out. The following rule was defined for coap-02:

1 If the Uri-Authority option is absent and the remainder of the URI uniquely identifies a resource the server MAY proceed to execute the request.

  1. If the server is able to determine the IP destination address of the request, it MAY assume this as the authority of the URI.
  2. If no authority can be determined and the server requires the authority to identify the resource it MUST reject the request with "400 Bad Request" [*]

[*] 400 Bad Request is pretty badly overloaded, so it is still to be determined if a new error code is needed for this case.

comment:2 Changed 12 years ago by zach@…

  • Resolution set to fixed
  • Status changed from new to closed

Rules added to Section 2.5.2 of coap-02 and proxy section fixed.

Note: See TracTickets for help on using tickets.