Explore at least one example of how HTTP should be used

[systemcrash]

There should be a short discussion about how and where to use plain old HTTP. The idea of the HTTPS record is for https endpoints. There is brief mention in a few places that HTTPS should not point to http (unexpected results), and attrleaf labels of http are forbidden in HTTPS.

SRV records were used for _http and _https but browser support never appeared. So there will be a number of home hobbyists (home routers with open source OS) and virtualization environments where http use may be necessary, and people generally searching for how to do HTTP only.

A correct example highlighting/contrasting HTTP use would be nice E.g.:

If HTTP usage is mandated, this can be achieved with the following example(s):

   _567._http.api.example.com. 7200 IN SVCB 0 svc4.example.net.

means "http://api.example.com:567" is aliased to "svc4.example.net".

   _http.api.example.com. 7200 IN SVCB 0 svc2.example.net.

means "http://api.example.com" is aliased to "svc2.example.net".

[bemasc]

I think HTTP-only endpoints are sufficiently well-served by the pre-existing DNS records. Systems that use plain HTTP instead of HTTPS generally do so in order to minimize complexity, so adding SVCB support there seems misplaced.

If you think this is worth pursuing, I suppose you can write a "SVCB mapping document" for the "http" scheme. However, ordinary web browsers are unlikely to implement it, and special-purpose clients are unlikely to need it, so I don't think it would be useful.

[systemcrash]

Not so much to support http - but SRV was commandeered by http users to direct to, not least of all, non-conventional ports. I was under the impression that browsers will implement SVCB, given that they manage a number of protocols (FTP, WS, etc etc). Maybe this case will never get supported...

[bemasc]

Browsers are implementing "HTTPS" queries, not "SVCB" queries, so they won't be looking for SVCB records when confronted with "http" URLs.

[marka63]

Firstly SRV for HTTP does not formally exist. For it to exist there needed to be RFC that says to do it or W3C needed to publish a document that said to do it. To the best of my knowledge neither happened.

Applicability Statement

In general, it is expected that SRV records will be used by clients for applications where the relevant protocol specification indicates that clients should use the SRV record. Such specification MUST define the symbolic name to be used in the Service field of the SRV record as described below. It also MUST include security considerations. Service SRV records SHOULD NOT be used in the absence of such specification.

There where a number of attempts to publish such a RFC but no traction was made.

[marka63]

I would hope that now the browsers are making HTTPS queries for https:, that they would be willing to make SRV or SVBC or some other type (HTTP?) queries for http: but for that to happen there needs to be a document that states that this is expected to happen. http: has all the same issues with wildcards as https: has so may be a new type is needed.

[bemasc]

No, browsers will make HTTPS queries when asked to connect to an http: URL (see Section 9.5).

[marka63]

Which, if found, requires https: to be used. It the operator doesn't want https: to be used there isn't a way to specify the server for http:/example.com/ is over here <server name,port> yet. We haven't solved the CNAME at the zone apex for http: only services.

[davidben]

It's 2022. Cleartext HTTP does not meet security expectations anymore.

If a SVCB mapping were defined, we would not implement SVCB for cleartext HTTP in Chrome. Any investment we make there would be better spent on migrating sites to HTTPS and, where not feasible, working on what makes it infeasible. Other features like HTTP/2, HTTP/3, and powerful platform features were similarly limited to HTTPS.

I was under the impression that browsers will implement SVCB, given that they manage a number of protocols (FTP, WS, etc etc)

WS and WSS work by mapping to HTTP and HTTPS first, so they wouldn't use SVCB. FTP has already been dropped by at least Chrome and Firefox. Not sure about other browsers. Beyond that, I can't think of any web-related protocol where SVCB could be applicable. If there were and it were something we wished to continue to invest in, supporting SVCB for it could be plausible, but we wouldn't extend that support to cleartext HTTP.

[bemasc]

Closing as out of scope