At some point you mentioned that you wouldn't really want an HTTP client library depending on Snap. Bit heavy, of course. However, for the usual case of POSTs of type application/x-www-form-urlencoded (and query string parameters too, should I ever include such a helper), one needs to properly encode things.
The code for urlEncode in Snap.Internal.Parsing is lovely, of course — and performant, too! It's sorta a no-brainer to use that, but to do so of course necessitates importing Snap.Core (urlEncode) which leads to the aforementioned dependency on snap-core.
I could just clone the code out lock-stock-and-barrel but it's a complicated piece of work and I'd hate to have to rip it off (and FastSet, and, and) just for this one function. So at the moment I've put a dependency on snap-core but I was wondering if things like this could be migrated to a snap-util package or so?
We spoke about this off-thread -- my position on this is that small amounts of code duplication is better than library proliferation. For http-streams it's worth reimplementing a bunch of 5-10 line functions in order to escape a dependency on snap-util or snap-core.