We plan moving to http/2 protocol for some of our providers.
Is this protocol already in SV roadmap?
I have a client that is requesting this support
Can one or both of you please clarify what features of HTTP/2 you are planning to use? I'm well aware of what is in the spec for HTTP/2, but it will help us prioritize feature implementation if we know what parts are most important / most common.
From the client
Here is some further detail and examples on the http/2 interface…
The interface uses the HTTP/2 protocol for message delivery. The protocol stack is HTTPS/TLS/TCP/IP. Not all features of HTTP/2 are used by the Server. This section describes how we expect the client to utilize the HTTP/2 capabilities. For a detailed description of HTTP/2, refer to RFC 7540.
The server expects that a client will open a single HTTP/2 TCP connection to the server, which will remain active for an extended duration of time, until either the server or client terminates the connection, or some type of connection error occurs. During periods of inactivity, the client must use the PING frame to verify connectivity and keep the TCP connection open through the network. It is the responsibility of the client to configure an appropriate PING interval and implement procedures to detect and recover from connection failures or other errors, such as PING timeout.
Should a connection unexpectedly fail or be closed while outstanding queries (open streams) exist, the client may resubmit the outstanding Reference Point queries over a different existing connection, or a newly established connection.
We will only support HTTP/2 over TLS. Therefore clients must include the HTTP/2 protocol identifier within the TLS ALPN. Clients should not attempt to connect via cleartext HTTP. The Server will not accept unencrypted connections or negotiate down to HTTP 1.1 protocol. TLS 1.2 must be used for this connection.
The Server will utilize default settings for each connection. Therefore the client should send an empty SETTINGS frame. The Server will ignore any settings requested by the client.
Each client Reference Point query will utilize a unique stream within a connection. Each stream is identified by a unique 31-bit integer. Stream Identifiers must always increase in value and cannot be re-used. For the query interface, the client will initiate all requests and will create all streams. The Server will not open streams or push data to the client (i.e. PUSH-PROMISE is not supported). Client-initiated streams utilize odd-numbered stream identifiers. It is recommended that the stream identifiers be sequential in number (i.e. 1,3,5,7, etc.), however the server will not look for or report on gaps in stream identifiers.
The client must create a new stream for each query. The Server will then respond to the request with either the desired requested information or an error. The stream will then be closed.
A client can open any number of simultaneous streams, depending on the number of Reference Point queries that are required at any given time, up to a pre-defined maximum limit for open streams. Streams are non-blocking requests, and Server will process all streams asynchronously, and may respond to streams in a different order than they were received. By default, the maximum number of open streams (MAX-SESSIONS) on a single connection is 32.
It is the responsibility of the client to anticipate the exhaustion of stream identifiers on an existing connection and open a new connection to Server when necessary. The Server will allow a client to have multiple connections active for this purpose.
The Server will not support stream priority. Priority information provided by a client will be ignored. All Reference Point queries will be given equal processing priority.
The Server does not support flow control. The interface messages are of consistent size and priority and the volume of queries from a single client is constrained by the number of open streams allowed on the connection. There is no need to apply flow control to the interface.
The server will not support stream dependencies. All Reference Point queries are independent transactions.
Required HTTP Headers are described in this section. HTTP/2 represents header fields using a compressed format within one or more HEADERS frames. The required headers for the interface messages are described similar to the examples in RFC 7540.
When the client queries the Server, the client uses the GET request method with URL parameters, similar to the following example:
There is no body for this request, therefore only minimal headers are required.
HEADER Flags: END_STREAM, END_HEADERS
:method = GET
:scheme = https
:path = /GetAddress/A0-12-34-56-78-90?Corr-ID=456…873
:host = OurServer.example.com
:accept = application/pidf+xml
The Method must always be GET.
The Scheme must always be “https”.
The Host identifies the domain/host name of the Server site.
The Path identifies the resource (Reference Point) being queried, plus the correlation parameter.
The Accept header must indicate support for PIDF-LO in the response.
If any other headers are sent, the Server ignores them.
In the HTTP successful response, the server includes the 200 OK result. An example of the successful response HTTP header is:
HEADER Flags: END_HEADERS
:status = 200
content-type = application/pidf+xml
content-length = nn
The server may send any of the HTTP errors defined in reference if the error occurs in the HTTP protocol layer. Application-level errors are returned within the body of an HTTP 200 OK response.
In the HTTP Error response, the server includes the Error code in the “status” header. An example of an HTTP error response header is as follows:
:status = 400
This interface supports a single service, the GetAddress request for translation of a reference point to a Civic Location. The client specifies the service via the URL of the HTTP GET request. The URL also contains the identity of the target device and other query parameters. The associated address is returned via a PIDF-LO object in the response. This section of the document describes the syntax of the request and response messages.
Below shows a detailed diagram of messages exchanged between the Client and Server.
The client sends the GetAddress request when it has one or more Reference Points to be translated to a Location. Each GetAddress request contains a single Reference Point ID and is delivered via a unique HTTP/2 stream over an existing TCP/IP connection. The Server will return the response over the same stream and then close the stream.
If the client has multiple Reference Points to resolve, multiple requests can be sent simultaneously by creating a unique stream for each request. Each stream is processed asynchronously, so one stream does not block the processing of other streams. Although the general behavior will be that the Server will return the responses in the order the requests are received, the independent nature of the streams allows for the possibility that responses are returned in an arbitrary order.
The client should send all Reference Point queries for the same location event (Correlation ID) over the same HTTP/2 connection, unless otherwise not possible. All requests can be sent simultaneously, presuming the connection has enough open streams available.
An example GetAddress request is shown below:
Within HTTP/2, the request is embodied within a single HEADER frame:
:path = /GetAddress/<Reference-Point>?Corr-ID=<Value>
The serverreturns the GetAddress response over the same stream used for the request and then closes the stream. In a successful response, Server will return the Location associated with the Reference Point, along with the geocoded coordinate location (Latitude/Longitude) of the address. In many cases the coordinate location is only an approximation of the address location, and should only be used by the client to assess the relevance of a particular Reference Point address to a known caller location.
An example LocationResponse is provided below:
One key feature for us in http/2 is the multiplexing over one connection in STREAM, as described below:
The Use Case request I saw at a customer installation was HTTP2 Server Push.
The server push allows the server to send a response to a given request and then preemptively accompany that response with another response to the client. I don't think this is the same as streaming but I have not reviewed the spec.
Close to the STREAM requirement describes above, do we currently support HTTP/1.1 persistent connection in DevTest?
Retrieving data ...