Re: Restricted ports Larry Masinter <email@example.com>
Subject: Re: Restricted ports
From: Larry Masinter <firstname.lastname@example.org>
Sender: Larry Masinter <email@example.com>
Date: Thu, 12 Aug 1993 22:24:57 PDT
It seems like bad design methodology to base protocol design on
a few special cases. So, try to decide in general whether allowing
HTTP connections to port 38 is a good idea, ignoring whether or not
there's one or two HTTP servers that listen on port 38.
Yes, if you disallow it, those sites will have to change to pick
other ports, but then, everybody's going to have to upgrade clients
anyway, and the owners of the servers can probably run another server
that listens on port 1083 too, leaving them both up for a while until
the extant URLs are fixed up.
If there weren't a simple migration strategy to more 'legit' ports,
I'd more sympathetic.
In fact, it would be lovely to suggest a couple of blocks of 'HTTP
port numbers', and ask everybody to migrate their usage to those.
(Well, for example, , how about 80-85 and 1080-1085?).
It would take a little while to transition, but then we'd get better
usage statistics, error checking, and less interference with other
As for gopher nodes that point to finger servers, humph. Just because
a gopher server says 'host: foo.baz.edu' 'port: 79' 'path: joe' doesn't
mean you have to translate it to the URL <gopher://foo.baz.edu:79/joe>.
Why not translate it to the URL <finger://foo.baz.edu/joe>
I mean, yes, gopher server maintainers rely on this hack in the gopher
clients that they're willing to open up unusual sockets, but that
doesn't mean that the URL has to say 'gopher:', does it?