search

t2trg / transports

Discovering and negotiating alternative transports for thing-to-thing communication
3 stars 0 forks source link

Find where elision of Uri-Host fits in #13

Open chrysn opened 5 years ago

chrysn commented 5 years ago

Requests being sent to hosts found by host-name that do not have a Uri-Host option are commonplace, IMO without actual justification (as this creates URI aliasing).

I think that within this WG we should find a way to justify when a Uri-Host can be left out, and that probably doesn't require much effort (only keeping-in-mind), but will come as a consequence of doing alternative transports efficiently (esp. of resolving the "sending the URI-Host repatedly" part of https://github.com/t2trg/transports/issues/5#issuecomment-511742499)

cabo commented 5 years ago

It really should be a form of compression: The host is in the URI (no URI aliasing), there is just no need to send it in the message if it can be inferred from the destination address.

(Whether coap://one.one.one.one/ is the same as coap://1.1.1.1/ would be a matter of URI aliasing, indeed. But leaving out Uri-Host on coap://1.1.1.1/ is not.)

chrysn commented 5 years ago

With requests targeted at resources at URI literal targets, this can be left out, no question. Also, in CoAP-over-TLS or WebSocket it can often be left out as its indicated in SNI and Host header field, respectively. (AFAIK there is no TLS equivalent Uri-Host default value in CoAP-over-DTLS).

What I see happening tough is that devices are configured to contact host.example.com resolve that to 2001:db8::1 and send a CoAP request there without a Uri-Host, even though the default Uri-Host value is 2001:db8::1 for that request.

They rely on their knowledge that the origin server does not do name-based virtual hosting, but that knowledge is equivalent to having received a URI equivalence statement. Alternative-Transports might provide them with such statements, or provide other means of compressing host information.