Clarify Transparent Proxies
This commit is contained in:
parent
1d86c2dbc6
commit
97c56f64a8
28
mhttp.md
28
mhttp.md
|
@ -126,21 +126,25 @@ The CDN must then repeat the exact same request it was given, as in plain HTTP/1
|
||||||
specify how to identify the client to the server] The server may then choose to send the CDN a
|
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.
|
response. However, the response has some key differences from HTTP/1.1.
|
||||||
|
|
||||||
First, the response starts with the server's certificate.
|
First, the response starts with the server's certificate.
|
||||||
|
|
||||||
Second, the response must contain the cache control headers:
|
Second, the response must contain the server's domain name and the resource path. We don't rely on
|
||||||
|
the server certificate's domain name because it may be valid for multiple domain names.
|
||||||
|
|
||||||
|
Third, the response must contain the cache control headers:
|
||||||
|
|
||||||
- `Expires`
|
- `Expires`
|
||||||
- \[TBD]
|
- \[TBD]
|
||||||
|
|
||||||
It should contain additional cache control headers for use by the CDN and client.
|
It should also 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
|
Fourth, the response (domain, path, headers and body) must be signed by the provided certificate's
|
||||||
private key). The certificate itself is not included in this signature.
|
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
|
If the CDN provides an expired response to the client, as defined by the `Expires` header, or a
|
||||||
client must warn the user and discard the response. To account for network latency, the CDN may
|
response for another domain or resource path, the client must warn the user and discard the
|
||||||
choose to expire the response a few seconds or a few minutes before the true expiry date.
|
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.
|
If the server chooses not to send the CDN a response, it can do so in the next scenario.
|
||||||
|
|
||||||
|
@ -159,3 +163,11 @@ connection closed, which could be caused by another network factor not involving
|
||||||
unnecessarily increase server load as well as reducing the reliability of the backwards
|
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
|
compatibility mechanisms, or it'd involve a reverse TCP connection and we already know how that
|
||||||
went for FTP.)
|
went for FTP.)
|
||||||
|
|
||||||
|
## Use by ISPs - transparent proxies
|
||||||
|
|
||||||
|
The CDN CA store is separate from the main CA store, and can only be used to sign CDN certs or
|
||||||
|
other CDN CA certs. This means it's fairly safe to put arbitrary certs in it. ISPs may use this
|
||||||
|
to provide transparent HTTPS proxies, in which case they act like a CDN as defined above, except
|
||||||
|
they do not send their cert upstream, instead relying on their capabilities as an ISP and using
|
||||||
|
the client's real IP address for the request.
|
||||||
|
|
Loading…
Reference in New Issue