162 lines
6.2 KiB
Markdown
162 lines
6.2 KiB
Markdown
# Mobile Hypertext Transfer Protocol, version 1.1
|
|
|
|
## Introduction
|
|
|
|
Mobile Hypertext Transfer Protocol (MHTTP) is a protocol that helps speed up the web and
|
|
protect it from DDoS attacks, while providing strong security guarantees. It's heavily
|
|
based on HTTPS, and also uses SCTP where available.
|
|
|
|
The "Mobile" in the name refers to mobile phones.
|
|
|
|
The MHTTP version tracks the corresponding HTTP version it's built on. As such, there's no
|
|
MHTTP/1.0 or MHTTP/0.9 as there are no versions of MHTTP built on those HTTP versions.
|
|
|
|
This protocol builds on:
|
|
|
|
- SCTP
|
|
- TLS Application-Layer Protocol Negotiation (ALPN)
|
|
- A new type of TLS certificate
|
|
- HTTPS/1.1 (HTTP/1.1 over TLS)
|
|
|
|
This protocol shall define the TLS ALPN protocol ID `"mhttp/1.1"`.
|
|
|
|
This protocol also makes use of the TLS ALPN protocol ID `"http/1.1"`.
|
|
|
|
## New certificate types (and new certificate authority types)
|
|
|
|
Two new kinds of certificates shall be created:
|
|
|
|
- \[TBD], the public-facing certificate type in mhttp/1.1.
|
|
- \[TBD], used by CAs to sign the above.
|
|
|
|
They have to be added so as to prevent Let's Encrypt from being able to issue them at the moment.
|
|
This is a temporary measure and should be revised once certificate providers adjust to this new
|
|
protocol.
|
|
|
|
## The Network Model
|
|
|
|
This protocol is built upon the following network model:
|
|
|
|
client <--------> CDN <--------> server
|
|
|
|
Currently, existing protocols are used to provide CDN services like so:
|
|
|
|
client <--HTTPS-> CDN <--HTTP--> server
|
|
|
|
## Securing communications between client and server
|
|
|
|
The MHTTP protocol attempts to secure communication between client and server through the whole
|
|
path. It puts both the client and the server in control, as it should be, where the existing
|
|
options put the CDN in control.
|
|
|
|
To be able to do this, it needs to cover a few different scenarios.
|
|
|
|
### Backwards compatibility with HTTPS, TCP, client certificates.
|
|
|
|
For backwards compatibility with HTTPS, TCP, client certificates, the following section applies,
|
|
but for all HTTP methods.
|
|
|
|
### Client-to-server (private) data
|
|
|
|
The most basic scenario is when sending "private" data. This is used when modifying server data.
|
|
This includes the following HTTP methods:
|
|
|
|
- POST
|
|
- PUT
|
|
- DELETE
|
|
- PATCH
|
|
- \[TBD]
|
|
|
|
In this scenario, the client may use a TCP or SCTP connection and must use the `"http/1.1"`
|
|
protocol. The CDN must pass this stream through unchanged, but may choose to restrict the client's
|
|
bandwidth and/or connection limits. The CDN must use SCTP for any connections to the server.
|
|
|
|
This scenario should be used whenever the client would make a request using one of the above HTTP
|
|
methods.
|
|
|
|
### Client-to-CDN, cached data
|
|
|
|
In most cases, the client wants to request data from the \[server/CDN] instead. In MHTTP/1.1, the
|
|
client must use an SCTP connection, and request the `"mhttp/1.1"` and `"http/1.1"` protocols, in
|
|
that order, in descending order of preference.
|
|
|
|
If a CDN exists and supports MHTTP/1.1, it must negotiate a TLS stream with the client using the
|
|
CDN certificate mentioned in section 2.
|
|
|
|
MHTTP/1.1 requests look just like HTTP/1.1 requests, but with some key differences:
|
|
|
|
- POST, PUT, DELETE, PATCH, \[TBD] are not supported.
|
|
- Cookies are not supported.
|
|
- "MHTTP/1.1" is used instead of "HTTP/1.1".
|
|
- \[TBD]
|
|
|
|
The CDN must cache based on at least:
|
|
|
|
- Resource Path
|
|
- Accept/Content-Type header
|
|
- Accept-Language header
|
|
|
|
If the CDN has the response in its cache, it should just send that response out, without hitting
|
|
the server.
|
|
|
|
The CDN should not choose to send the same response for different Accept headers, and should take
|
|
preference into account if doing so. For example, if the first request contains the header:
|
|
|
|
Accept: */*
|
|
|
|
And the response contains:
|
|
|
|
Content-Type: text/html
|
|
|
|
But the second request contains:
|
|
|
|
Accept: application/xhtml+xml, text/html; q=0.5
|
|
|
|
Then the CDN should hit the server for an `application/xhtml+xml`. If one is found, a subsequent
|
|
request with `Accept: */*` may retrieve an `application/xhtml+xml` instead of `text/html`.
|
|
|
|
If the CDN does not have the response in its cache, the next scenario applies.
|
|
|
|
### Client-to-CDN, uncached data
|
|
|
|
If the CDN does not have the response in its cache, it must open a stream to the server, using the
|
|
`"mhttp/1.1"` protocol and the CDN certificate as the TLS client certificate.
|
|
|
|
The CDN must then repeat the exact same request it was given, as in plain HTTP/1.1. \[TODO:
|
|
specify how to identify the client to the server] The server may then choose to send the CDN a
|
|
response. However, the response has some key differences from HTTP/1.1.
|
|
|
|
First, the response starts with the server's certificate.
|
|
|
|
Second, the response must contain the cache control headers:
|
|
|
|
- `Expires`
|
|
- \[TBD]
|
|
|
|
It should contain additional cache control headers for use by the CDN and client.
|
|
|
|
Third, the response (headers and body) must be signed by the provided certificate's key (server's
|
|
private key). The certificate itself is not included in this signature.
|
|
|
|
If the CDN provides an expired response to the client, as defined by the `Expires` header, the
|
|
client must warn the user and discard the response. To account for network latency, the CDN may
|
|
choose to expire the response a few seconds or a few minutes before the true expiry date.
|
|
|
|
If the server chooses not to send the CDN a response, it can do so in the next scenario.
|
|
|
|
### CDN-mediated client-to-server, (true) private data
|
|
|
|
If the server doesn't want the CDN to cache a GET/\[TBD] request, it can open a new SCTP stream
|
|
for sending the data directly to the client.
|
|
|
|
If the server opens an SCTP stream to the CDN instead of responding to a request, the CDN must
|
|
forward this new stream as a new stream to the client. The client should then start a TLS
|
|
handshake with the server, using the `"http/1.1"` protocol, and run a normal HTTP request with
|
|
all normal HTTP headers, including cookies. See the backwards compatibility section for details.
|
|
|
|
(This requires SCTP because TCP-based alternatives would either require the CDN to signal a
|
|
connection closed, which could be caused by another network factor not involving the CDN, and thus
|
|
unnecessarily increase server load as well as reducing the reliability of the backwards
|
|
compatibility mechanisms, or it'd involve a reverse TCP connection and we already know how that
|
|
went for FTP.)
|