The code was assuming that the record type was
MX even though this could be false. Also adjusted
some code to also make it easier to test.
Note: the behavior when MX records are missing
is probably still not right.
Closes PR 13654
* Some racketisms.
* Use explicit `in-list' etc in for loops.
* Remove some redundant requires from `net/dns'.
* Move all tests to `tests/net', including a new `tests/net/ip'. In the
future there's a plan to have things like stripped zos etc for
distribution, but we're not there yet, and the net collection is
already organized nicely so this also makes it more uniform.
* Include the dns tests in the main test file.
The library currently lives in a private subfolder so
that the interface can still be changed. The idea is to
eventually make it a top-level `net` library once it is
more mature.
Changing `current-url-encode-mode' from 'recommended to 'unreserved
causes `url->string' to encode !, *, ', (, and ) using %, which
can avoid confusing some parsers.
See also https://github.com/plt/racket/pull/198
The revised protocol for a progress procedure doesn't create
the thread automatically, and it provides an event to indicate
when the progress count changes.
If a path to a directory is converted to an URL it loses
its trailing path separator.
This can lead to a bug if the URL is used as a base URL to
build other URLs (e.g. combine-url/relative).
A port over which a redirection is served to get-pure-port is not closed
if `get-pure-port' follows the redirection. This leaks file descriptors
on the host machine.
the errors that would be signalled by the body. also, remove
url-regexp from the exports (it was only recently added)
I believe this eliminates two of Eli's concerns:
- the contract is no longer so painful to read
- the performance is more reasonable.
Specifically, for the performance, here are the times I see to call
string->url on "http://www.racket-lang.org":
no contract: any/c
cpu time: 564 real time: 566 gc time: 3
weak contract: (-> (or/c string? bytes?) url?)
cpu time: 590 real time: 590 gc time: 3
strong, regexp-based contract:
(-> (or/c (not/c #rx"^([^:/?#]*):") #rx"^[a-zA-Z][a-zA-Z0-9+.-]*:") url?)
cpu time: 632 real time: 633 gc time: 5
This appears to be about a 10% slowdown for the regexp-based contract
over the weaker contract.
related to PR 12652
