An HTTPS Endpoint Does Not Establish the Negotiated Inference Protocol

Locate the connection behind the HTTPS claim

A buyer receives an inference proposal with an HTTPS endpoint and an HTTP/2 concurrency figure. The immediate question is whether the figure describes the connection the intended client will actually use. A protocol capability in the proposal and a result from that client connection are different evidence.

RFC 9113, published in June 2022, explains that HTTP/2 and HTTP/1.1 share URI schemes and default port numbers. The URI does not identify the HTTP versions supported by the immediate peer. Naming port 443 therefore does not resolve the version question.

Request an account that names the client, its immediate TLS peer and the connection associated with the reported result. Keep that identity attached to the later stream observation. A TLS-version or certificate field answers another question; neither field is the selected application-protocol value.

References: [H9113]

Read the offer and the selection as different messages

RFC 7301 (July 2014) defines ALPN. The client offers names in descending preference order. The server selects exactly one offered protocol that it supports. It should choose its own most preferred common protocol; the first client entry alone does not determine the result.

This distinction changes how to read a proposal's evidence. A client-side list containing h2 and http/1.1 describes candidates. A product description saying both are supported describes capability. Neither substitutes for the selection response associated with the connection under review.

The IANA ALPN registry identifies http/1.1 as HTTP/1.1 and h2 as HTTP/2 over TLS. It reserves h2c for cleartext HTTP/2 and explicitly excludes that identifier from TLS ALPN negotiation. Preserve the exact names when interpreting an evidence extract; treating h2c as another spelling of h2 would change its meaning.

References: [A7301][IANA]

AL-64: the same client offer produces two different results

Original fictional case AL-64 compares one client C with endpoints A and B. Both proposed connections use TLS 1.2. Stipulate that all other applicable TLS requirements, and HTTP/2 requirements wherever HTTP/2 is selected, are satisfied. This isolates protocol selection; no handshake or performance test was performed.

C offers the ordered list h2, http/1.1 to each endpoint. A supports both and prefers h2. Stipulate that A selects h2 and the TLS handshake completes. B supports only http/1.1. Stipulate that B selects http/1.1 and its handshake also completes.

The intersection for A contains two candidates; its selection is one of them. The intersection for B contains only http/1.1. Both connections fit an HTTPS description and the same TLS-version label. They also began with the same two client names, yet their selected application protocols differ.

Suppose the accompanying proposal has an HTTP/2 stream figure without identifying its connection. The A result makes an HTTP/2 interpretation relevant to A's connection, subject to the actual exchange evidence. The B result gives no basis to apply that HTTP/2 figure to C-B. A capacity comparison that combines the two would lose the distinction established by the example.

Neither selection establishes whether a particular inference request completed. AL-64 supplies no request outcome, batch assignment or elapsed time. Those missing observations remain missing even for A.

References: [A7301][IANA]

An h2-only offer changes B's outcome

Now give AL-64 a separate client D that offers only h2 to the same ALPN-participating endpoint B. B still supports only http/1.1. The lists have no common member. RFC 7301 requires a fatal no_application_protocol alert in that situation.

This variation has no selected HTTP/1.1 result: D did not offer it. The earlier C-B success cannot supply compatibility for D-B. A buyer whose intended client requires HTTP/2 must evaluate that client's contract, rather than treating another client's successful connection as interchangeable evidence.

Keep an absent ALPN result separate from this explicit no-common-protocol case. A record with no selected value establishes neither h2 nor a particular failure cause. The example does not claim that every server lacking an ALPN response necessarily sends this alert.

References: [A7301]

Connect selection to the HTTP exchange and then to inference

Selection resolves which protocol the peers agreed to use. RFC 9113 separately requires connection prefaces after TLS negotiation; these confirm HTTP/2 use and establish initial settings. Negotiation evidence and evidence of the ensuing exchange therefore answer successive questions.

For A, a report containing a selected h2 value but no account of subsequent HTTP traffic can support the negotiation statement. It cannot document an unreported request or response. Conversely, an evidence extract labeled HTTP/2 needs enough connection identity to relate it to the client-facing claim, rather than a different part of the system.

Once the relevant HTTP/2 connection is established, use the related HTTP/2 streams guide to interpret the active-stream population and the peer's limit. It explains how transport streams relate to application requests, batches and workers.

A selected h2 value does not name a model, request schema or response format. For the serving purchase, join the named request to its application outcome and any claimed timing. A supported protocol, a selected protocol, an HTTP exchange and a completed useful inference are successive claims requiring their own evidence. A correct earlier claim does not supply the later result.

References: [H9113]

Keep each connection's result within its boundary

RFC 7301 defines ALPN for the connection, rather than the session, and uses new handshake values for resumption. An earlier result does not permanently characterize an endpoint.

There is another boundary when the immediate TLS peer is a terminating HTTP gateway. RFC 9110's June 2022 intermediary model describes a chain of separate connections and permits a gateway to use another protocol toward its servers.

Extend AL-64 by stipulating that A terminates C-A and forwards requests to backend O. The selected h2 result remains attached to C-A. No A-O protocol evidence has been supplied, so an end-to-end HTTP/2 claim remains unresolved. This extension concerns a terminating participant, rather than equipment merely carrying the traffic.

Apply these results to the offer. With only an HTTPS label or support list, request the missing connection-specific selection evidence. With B's selected http/1.1 result, do not apply an HTTP/2 stream account to C-B. With A's selected h2 result and an established HTTP/2 exchange, proceed to the existing stream guide while retaining the request-to-serving mapping as a separate requirement.

The related TLS 1.3 guide addresses resumption, early data and replay exposure. Use it for that security and processing-timing question.

References: [A7301][H9110]

Carry a separate cabling need into the physical project

If the selected equipment also needs physical connections, Leviathan's Structured Cabling & Fiber Installation service can discuss agreed endpoints, routes, labels and connection records using customer-furnished or separately sourced materials. Use the related service and project inquiry with a nonconfidential outline of that physical requirement.

Those records identify the installed connections. TLS negotiation, gateway software and application acceptance belong with the appointed network, application and security owners; the cabling inquiry concerns the agreed physical installation.

References: [L1]