Regarding the immediate problem, and then a couple things you might see
after...
* Unless you have a really weird OS, I think the first problem is that
another process currently has/had port 443 open on the same network
address. (This might even be from the last run of your same program, as
the OS finishes shutting down TCP for that socket on that address. Or
it could be a Web server software that was installed on your
workstation, or from some other development tools you also ran. Or I
suppose it could be weird security software on the machine itself.)
If you're on GNU/Linux, you probably have an `lsof` command (the name
comes from "list open files" including TCP ports), which would let you do:
lsof -i :443
If it's still a headscratcher, double-check what interface IP
address(es) it's trying to listen on, make sure they're correct, and
first try to access port 443 on the addresses in a Web browser
(preferably with plausible FQDNs). It's probably something very simple,
but small chance it's something annoying, like broken routing, broken
name resolution, or naughty OS tricks that something else installed on
your workstation is doing.
* After you solve that problem, I think you're right: listening on the
special low port number 443 would normally require root privileges
(though maybe not on some non-Unix OS). I think that particular Racket
document should be changed to at least mention the problem. (I won't
try to say offhand exactly what the default advice in the Racket docs
should be for using 443 -- there's so many ways to do this, all with
different pros&cons for different needs, even if the software defaulted
to automagic. But the problem should at least be mentioned.)
* A possible third difficulty after that is that, not only is the whole
HTTPS dependency on CAs imperfect, it's an annoyance for development,
and easy to make it awful.[1]
If you want to do lightweight development from your workstation, and
your workstation has a stable, unique FQDN, which isn't easily mistaken
for production, such as
"workstation-451.development.internal.mycompany.com", one possibly-OK
way might be to get a cert for that exact FQDN, signed by whatever CA is
already trusted by browsers of people who would be using it.[2]
Or, I've also made my own CA sometimes in the past, trusted only by
myself. But that requires adding the CA as trusted to browsers, which
has its own security downsides, and can be a headache to figure out how
to do all the browsers and handhelds you go to test with.
Also, you need to decide whether you want Racket doing the SSL/TLS, or
some program fronting it. There are numerous ways to front it. Two
effects of using a separate Web server on the workstation to front are:
(1) it can solve the problem with the privileged port number (without
Racket process needing to worry about how to do that); and (2) it could
even (for better or worse; but maybe better for some students) hide the
cert key from the developer (and use OS security mechanisms more
sophisticated than root-only-low-TCP-ports to control who on the
workstation can provide the behavior behind 443, and in what way).
* These are little details of history, and knowing about them doesn't
feel very smart. We want to be smart about things much more grand. :) [3]
[1] Example: Recently, I was considering a job developing a big
enterprise cloud infrastructure technology thing. While going through
the company's main tutorial for outside enterprise developers/devops, I
saw they were having developers run their tutorial app using URLs
through a not-very-reassuring third-party dotcom, as a kind of proxy --
without any mention that this is arguably a very bad idea for almost
anyone, much less anyone doing "enterprise-grade". I think we can make
a good guess that many of those enterprise developers, already
overwhelmed with this huge mass of framework stuff that almost no one
fully understands, are going to assume this is the way it's done, and
end up doing production work with sensitive data in an insecure and
unstable way. (It gets even better: I then found a support post
responding to the event of that third-party dotcom breaking... and the
official enterprise infrastructure response to users was to switch over
to a different third-party dotcom proxy thing -- perpetuating the bad
idea, even while looking at a real-world example of one of the ways it
can fail.) Seemed like, eventually, someone is gonna get trampled by a
HIPAA-potamus, or other painful enlightenment.
[2] Preferably an organization-internal CA, to reduce phishing of
outside users, were your workstation compromised more easily than
production servers are. (The failure of cert-based server
authentication, for outside users who don't trust that
organization-internal CA, should scare away people who don't know what a
development workstation means.) Also, if the organization does this,
they have to be careful that all its important Web servers were set up
properly, or a development workstation server could steal browser
cookies from other servers.
[3] But trivia can pay off. Without spoilers, if anyone has not seen
the film "My Cousin Vinny", I recommend watching it in its entirety.
--
You received this message because you are subscribed to the Google Groups "Racket
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
