@cyphar's distribution-uri ABNF used authority, but I used host in #2 because:
Where they're needed, I expect users to be providing userinfo and port information via other channels, especially since docker etc. currently use : to delimit tags.
In #5 (here) and #7 (here), @xiekeyang has wanted support for localhost:8080/…. I understand that is useful for testing, but don't think it should part of the host-based image name spec.
The .well-known URL lookup functions over both HTTP and HTTPS (e.g. see here). But if you are extracting the port from the image name, there's no way to know which protocol to use except by attempting both on that port. Trying to connect to a server using the wrong TLS protocol and finding out that you picked the wrong protocol (which is what would happened if we tried HTTPS and HTTP on localhost:8080) seems like a bigger issue than trying to connect to a server on the usual port for the protocol and finding out that the server is not listening on that port at all (which is what happens in our current protocol polling).
And I see no value to being able to specify explicit ports in production. Do we really expect production users to enter example.com:8080/… image names? Why would the example.com admins not be serving those images from 443 or 80?
There is a benefit for testing, because you don't need root on your host box to test if you can point the ref-engine discovery client at a high port. But I think we should find a way to work around that in testing (some ideas here, although we don't have anything trivial yet), instead of relaxing the production host-based image name spec.
@cyphar's distribution-uri ABNF used
authority, but I usedhostin #2 because:In #5 (here) and #7 (here), @xiekeyang has wanted support for
localhost:8080/…. I understand that is useful for testing, but don't think it should part of the host-based image name spec.The
.well-knownURL lookup functions over both HTTP and HTTPS (e.g. see here). But if you are extracting the port from the image name, there's no way to know which protocol to use except by attempting both on that port. Trying to connect to a server using the wrong TLS protocol and finding out that you picked the wrong protocol (which is what would happened if we tried HTTPS and HTTP on localhost:8080) seems like a bigger issue than trying to connect to a server on the usual port for the protocol and finding out that the server is not listening on that port at all (which is what happens in our current protocol polling).And I see no value to being able to specify explicit ports in production. Do we really expect production users to enter
example.com:8080/…image names? Why would the example.com admins not be serving those images from 443 or 80?There is a benefit for testing, because you don't need root on your host box to test if you can point the ref-engine discovery client at a high port. But I think we should find a way to work around that in testing (some ideas here, although we don't have anything trivial yet), instead of relaxing the production host-based image name spec.