make hyperlink handle + like an HTML form post by default

[glyph]

Per the interminable discussion already present there, fixes #129.

[codecov]

Codecov Report

Merging #145 (b06994b) into master (e362c53) will increase coverage by 0.02%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master     #145      +/-   ##
==========================================
+ Coverage   98.67%   98.69%   +0.02%     
==========================================
  Files          13       13              
  Lines        1809     1840      +31     
  Branches      209      212       +3     
==========================================
+ Hits         1785     1816      +31     
  Misses         12       12              
  Partials       12       12              

Impacted Files	Coverage Δ
src/hyperlink/test/test_url.py	99.82% <ø> (ø)
src/hyperlink/_url.py	96.98% <100.00%> (+0.06%)	⬆️
src/hyperlink/test/test_decoded_url.py	100.00% <100.00%> (ø)
src/hyperlink/test/test_scheme_registration.py	100.00% <100.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update e362c53...b06994b. Read the comment docs.

[wsanchez]

Looks good.

One question: do we really want to default to this for all schemes? I'm worried in particular about urn: schemes, though even in that case, perhaps the right answer is just "don't use + in URLs".

[twm]

Unfortunately it's not just DecodedURL — URL also corrupts +. This PR demonstrates the issue: #146

[twm]

👍 Thank you for this! I'll update and release treq to depend on new Hyperlink version as soon as this has been released. That'll unblock Klein.

[glyph]

Looks good.

One question: do we really want to default to this for all schemes? I'm worried in particular about urn: schemes, though even in that case, perhaps the right answer is just "don't use + in URLs".

The relevant specification for URNs seems to be https://tools.ietf.org/html/rfc8141#section-2.3.2 - previously, query parameters basically weren't used in URNs; https://tools.ietf.org/html/rfc2141 specifically punts on the issue. And the bananas new syntax in 8141 is going to require extensive changes in hyperlink to accommodate- for example, the URN equivalent of query components are now introduced by "?=" or "?+", not just "?".

In any event, URNs are not URLs so are in some sense out of scope for this library ;-).

I think if we want to handle these properly, we may want a new "URN" wrapper class which inherits this behavior and introduces the appropriate constraints (no netloc, for example) for URNs.

Given all this knock-on complexity, I'm going to go ahead and land it. I'm by no means opposed to supporting URNs, "q-component" and all, but we don't before this change and adding it won't change anything. (Arguably it will make it easier to build proper support on top of URL, although it will admittedly make DecodedURL a little more of a pain.)