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.
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
There might be existing uses of `net/sendmail' that did this quoting
since this code didn't do so. Such uses would continue to work fine,
since quoted strings would already be plain ASCII, so a second quoting
would leave it as is.
Note that the quoted strings are also used as command line arguments.
It seems that sendmail deals with these all fine when they appear as
command line arguments. This means that any valid email address format
can be used, not just "raw" emails. If there are some sendmails that
don't do this, then it would be better to add a `-t' flag to let
sendmail parse the text in the message.
One caveat (not a new one): since they're passed as is, it is possible
to use two emails in a single string, as in "a@b.com, c@d.com". This
could lead to obvious problems if someone uses "Bar, Foo <foo@bar.org>"
instead of "\"Bar, Foo\" <foo@bar.org>". (Using a `-t' to parse the
content won't help with that...) The only way to avoid this would be to
parse the emails and quote the name part if needed. But that's a much
hairier piece of code.
* Move the `X-Mailer' header to the top, so that the interesting headers
are all together at the bottom (the top gets littered by server
headers anyway).
* Use `subprocess' directly (`process*' wasn't really doing anything
more than that).
* Allow the sender to be `#f', leaving the header out. This makes all
sendmails that I've used use the username that is running the process.
* Just search for a sendmail program: don't barf on windows, so it can
be used in case there is a sendmail.exe executable there.
* Remove `no-mail-recipients' to make it in-line with other racket code
that doesn't raise super-specific exceptions.
* Use port counting instead of doing the counts manually, much simpler
code.
This takes the advice from
http://files.stairways.com/other/ftp-list-specs-info.txt
further: search for the date by an explicit occurrence of a known month
name. This means that we won't see files with bad names (they'd be
filtered out of the result), but the filtered out entries are ones that
would not be usable with `ftp-make-file-seconds'.
When the month is found, and the entry is a file, look for a number
preceding the month, and if found, return it as the file size string.
This is a minor change in the API. (But it's probably better to either
revise it further, or eventually make it irrelevant by exposing the
interesting functionality via `net/url'.)
