CDNTP... sort of.
This commit is contained in:
commit
1d86c2dbc6
|
|
@ -0,0 +1,161 @@
|
|||
# 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.)
|
||||
Loading…
Reference in New Issue