Garrett, are these rules documented somewhere? I did a quick search through
the nng documentation, but didn't see them.
Thanks,
Cem Karan
---
Other than quoted laws, regulations or officially published policies, the views
expressed herein are not intended to be used as an authoritative state of the
law nor do they reflect official positions of the U.S. Army, Department of
Defense or U.S. Government.
-----Original Message-----
From: nanomsg-bounce@xxxxxxxxxxxxx [mailto:nanomsg-bounce@xxxxxxxxxxxxx] On ;
Behalf Of Garrett D'Amore
Sent: Tuesday, January 23, 2018 12:03 AM
To: nanomsg@xxxxxxxxxxxxx
Subject: [Non-DoD Source] [nanomsg] URL changes in nng…
All active links contained in this email were disabled. Please verify the
identity of the sender, and confirm the authenticity of all links
contained within the message prior to copying and pasting the address to a
Web browser.
________________________________
(If you use nng and any of the ipc, websocket, or zerotier transports, this
message describes an important, and possibly — but probably
not — breaking change that has been made to nng today. If that’s not you,
feel free to discard this message.)
So as part of “cleaning up” the nng URL handling, and providing consistency,
I’ve changed the code (and docs) as follows:
ipc:// urls are now like file name urls, but they don’t recognize localhost
(yet). Instead you pass ipc:/// or ipc://*/ There is no more
support for relative paths in the IPC transport.
Support for ‘*’ as an alias for “self” is restored everywhere it meant
something.
ZeroTier (if anyone is using it) got a total URL format change (reviewed with
the one known ZT consumer). It is now
zt://<nodeid>.<nwid>:<port> — this is closely aligned semantically to other
URLs, instead of the weird and inconsistent URL syntax we
had before.
In the near future I’ll probably document that inproc:// has a “hostname”
component just like ipc does. For now the code more or less
ignores what you put there, although the first string between :// and the
next / is treated as a hostname and converted to lower case. (A
subtle concern now — if you rely on case alone to distinguish keys in this
first field, you may be “surprised”. I suspect nobody is doing
that.)
In all cases, we “canonify URLs”, as follows:
* hostnames (and schemes) are converted to lower case
* ASCII alphanumerics and _, -, ~, and . are “unescaped” if present as
escaped fields in the “path” component of a URL.
* Non-ASCII characters (UTF-8) are unescaped, but checks are made to make
sure that the UTF-8 is strictly valid and does not use
redundant encodings (security). These checks are *not* performed for
anything appearing after a “?” or “#” in a path (like a fragment or
HTTP query info).
* Paths are “resolved” with multiple /s reducing to a single /, the . and ..
elements are applied in the “normal” fashion. As with the UTF-8
stuff, these changes are not made for the elements of a path appearing after
a “?” or “#”.
The upshot of the above is that URLs are treated much more like web/internet
URLs, and indeed we now support those (wss:// and ws://
and in some places Caution-http:// and Caution-https://) so things should be
much much more consistent.
A downside is that this may be breaking for some folks that used unusual
characters in their paths or URLs. If you have questions about
that, don’t hesitate to ask me. Note that none of these changes apply to
“legacy” nanomsg.
(If you have a legacy server exposing a URL with “funny characters” in it,
you can still make that URL work, but you may need to “percent
escape” the offending characters when talking to such services with nng.)
Btw, in the next day or two, I expect to start making changes to expose (and
document) the server side HTTP API, so that people can make
their HTTP and HTTPS servers (for example to serve up JavaScript apps that
talk to nng.) Stay tuned.
- Garrett
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
