125159 - [RFE] URLs can't contain service names instead of port numbers

Status: VERIFIED INVALID

(Core :: Networking, enhancement)

Description

[Mike Hicks]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.0.2 (X11; Linux i686; U;) Gecko/20011224
BuildID:    

When attempting to connect to an HTTP server on a non-standard port, it's not
possible to replace the port number with the service name (found in
/etc/services).  For example, to configure CUPS (common Unix printing system) on
my computer, I need to connect to an HTTP server on the IPP (internet printing
protocol) port of 631.

Connecting to http://localhost:631/ works, but http://localhost:ipp/ does not
work, even though an appropriate entry exists in /etc/services.

Reproducible: Always
Steps to Reproduce:
1. have CUPS or some other HTTP service running on a port named in /etc/services
2. attempt to connect to http://hostname:servicename/


Actual Results:  The connection was refused when attempting to contact localhost.

If a webserver is running on port 80, the page that you'd get by going to
http://hostname/ is displayed.

Expected Results:  I'd expect to connect to the appropriate port, rather than
port 80, and get a web page if one is provided..

Comment 1

[[e-mail]]

I don't think this is supported by an URL RFC's. There are problems which
involve the usage or editing of /etc/services on multi-user systems. Some people
argue that it is a map for outbound ports, others say that it is a map for
running services on that system.

Comment 2

[benc]

QA futuring of various bugs to focus on remaning bugs. If you think your bug
needs immediate attention for Mozilla 1.0, set the milestone to "--". I will
review these bugs (again) later.

Comment 3

[Nicolás Lichtmaier]

According to RFC 1738 section 3.1 the port is only digits. So this RFE is
requesting the Mozilla accepts invalid URLs. Marking this bug INVALID.

Comment 4

[benc]

VERIFIED:
it's a good idea, but not in the spec, and probably for good reasons.

Comment 5

[benc]

I found the good reason in RFC 1700 while doing some research:

Some service names ("keywords) include characters that would create problems in
a URL:

cl/1, port 172.

:)

Comment 6

[benc]

*** Bug 220473 has been marked as a duplicate of this bug. ***