The indirection uses a "local-redirect.js" script to rewrite
the document links to local links within the browser. This mechanism
is a step towards distributing compiled packages that include
already-built documentation, where paths to other documentation
can be different than in the build environment.
If the links are not rewritten, they are queries to
"pkg-docs.racket-lang.org", with the idea tha such a server will exist
for reading all package documentation online. Also, a package's
documentation that refer to documentation for uninstalled packages,
in which case the corresponding links will not get rewritten and
will continue to point to the server.
Rendering the "local-redirect.js" script spends a lot of time just
converting among different path formats. Various library changes in
this commit are aimed at speed up those conversions, but the big
improvement came from a `path->url-string' that shortcuts conversion
os simple Unix paths.
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
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
