Incorrect use of SRV with http:// URLs

infracaninophile commented 11 years ago

As pointed out by Garrett Wolmann in private e-mail, using a repository URL of the form:

    http://pkg-test.freebsd.org/...

Where the hostname part should be resolved by a SRV record in the DNS, eg:

_http._tcp.pkg-test.freebsd.org. 120 IN SRV 10 10 80 pkg1.nyi.freebsd.org.

is incorrect according to the specification of http:// URIs in RFC 2616 Section 3.2.2

The correct mechanism is to follow RFC 4395 and register our own pkg specific service types. See:

https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml#uri-schemes-2

so, for example we could have URLs of the form

   pkg://pkg-test.freebsd.org/

or

   pkg+http://pkg-test.freebsd.org/

and DNS SRV records like:

_pkg+http._tcp.pkg-test.freebsd.org. 120 IN SRV 10 10 80 pkg1.nyi.freebsd.org.

It would be good to have some way of specifying the transport protocol (HTTP, HTTPS, FTP, SSH, file etc.) for each of the alternate sites specified in the SRV RR data so this may be discovered automatically, but I can't see a way to do that well: intuiting from the port number in the SRV RR data is feasible, but too inflexible.

bdrewery commented 11 years ago

:thumbsup: to stop using "http://".

infracaninophile commented 11 years ago

After talking with bapt at EuroBSDCon:

Should be in 10.x
However can change /usr/sbin/pkg in 8,x, 9.x < 9.3
Keep current http:// SRV behaviour, but add deprecation warnings depending on OS version
Implement pkg+foo:// scheme where foo in {http,https,ftp,ssh,file,...}
No plain pkg:// URLs
pkg+file:// may not obviously make a lot of sense but it means we can have clickable links in eg. FireFox that do pkg related things.
Implementation is fairly simple -- just detect and skip over the 'pkg+' bit of the URL, and the rest of the processing is the same as before.

bapt commented 11 years ago

fixed

melvyn-sopacua commented 10 years ago

This conflicts with RFC 6335, section 5.2:

The DNS SRV specification [RFC2782] states that the Service Label
part of the owner name of a DNS SRV record includes a "Service"
element, described as "the symbolic name of the desired service", but
as discussed above, it is not clear precisely what this means.

This document clarifies that the Service Label MUST be a service name
as defined herein with an underscore prepended.  The service name
SHOULD be registered with IANA and recorded in the Service Name and
Transport Protocol Port Number registry [PORTREG].

The grammar for a service is given in the previous section and does not allow for the + character:

SRVNAME = *(1*DIGIT [HYPHEN]) ALPHA *([HYPHEN] ALNUM)

My hoster (TransIP.nl) also does not allow the + character. I also cannot find any reference to using a + sign in SRV records other then this thread. The NAPTR record is made for this and can forward "specialization+service" to an SRV record that specifies the IANA registered service.

infracaninophile commented 10 years ago

On 30/03/2014 10:15, Melvyn Sopacua wrote:

This conflicts with RFC 6335, section 5.2:
The DNS SRV specification [RFC2782] states that the Service Label
part of the owner name of a DNS SRV record includes a "Service"
element, described as "the symbolic name of the desired service", but
as discussed above, it is not clear precisely what this means.

This document clarifies that the Service Label MUST be a service name
as defined herein with an underscore prepended.  The service name
SHOULD be registered with IANA and recorded in the Service Name and
Transport Protocol Port Number registry [PORTREG].
The grammar for a service is given in the previous section and does not allow for the + character:
SRVNAME = *(1*DIGIT [HYPHEN]) ALPHA *([HYPHEN] ALNUM)
My hoster (TransIP.nl) also does not allow the + character. I also cannot find any reference to using a + sign in SRV records other then this thread. The NAPTR record is made for this and can forward "specialization+service" to an SRV record that specifies the IANA registered service.

Your hoster is way too uptight. Use of '+' in SRV records is a well established practice. For example, see prior art here, in IANA's own listings:

https://www.iana.org/assignments/uri-schemes/prov/svn

Matthew

Dr Matthew J Seaman MA, D.Phil.

PGP: http://www.infracaninophile.co.uk/pgpkey JID: matthew@infracaninophile.co.uk

melvyn-sopacua commented 10 years ago

That's a URI. Can you show me the standard that defines that the scheme part of a URI should directly match the service name of a SRV record and the updated SRV grammar? The only mention here is about URI's. I'm not contesting the URI format. None of the RFC's you quote talk about SRV records.

melvyn-sopacua commented 10 years ago

In fact, one of the longest outstanding bugs is that browsers don't support SRV records. This applies to a lot of client tools invented in that era. SMTP implements MX, which is basically a shorthand SRV record.

I've always considered the + sign a separator between application protocol and communication protocol. Like mercurial can handle git+ssh, using ssh as the communication protocol to fetch remote data and git to know how to use the data once it's retrieved.

SRV records are about what communication and transport to use to retrieve (or deliver) data and is application agnostic. This is why it has only two parts, matching /etc/services and /etc/protocols.

P.S. It's not about my hoster, it's simply what prompted my research into this. I can delegate to my own servers if needed.

freebsd / pkg

Incorrect use of SRV with http:// URLs #550