- From: Kari Hurtta <hurtta-ietf@elmme-mailer.org>
- Date: Fri, 3 Mar 2017 07:11:38 +0200 (EET)
- To: HTTP working group mailing list <ietf-http-wg@w3.org>
- CC: Mike Bishop <Michael.Bishop@microsoft.com>, Alex Rousskov <rousskov@measurement-factory.com>, Willy Tarreau <w@1wt.eu>, Kari Hurtta <hurtta-ietf@elmme-mailer.org>
> > Mike Bishop <Michael.Bishop@microsoft.com>: (Thu Mar 2 00:35:11 2017)
> > > A couple problems with that model. First, the wholly protocol-based: A stream is opened by a HEADERS frame; sending an earlier frame on a stream is a breaking protocol change that would require negotiation prior to use. (Sending the frame between HEADERS and DATA, and requiring a zero-length DATA frame to close the stream might be a reasonable workaround to this.)
> > >
> > >
>
> There may be reason to send SETTINGS frame with
>
> TRUSTED_PROXY_CONFIGURED = 1
>
> from browser to proxy, but reason is not
> "Origin certificate" -frame. I think
> that stream is open on that situation even
> when it is first frame on direction
> proxy -> browser.
>
>
> Sequence A: (HTTP/2 inside of TLS connection between browser and broxy)
>
>
> browser => proxy
> HEADERS (stream 1)
> - END_STREAM
> + END_HEADERS
> :method = CONNECT
> :authority = example.com
>
> proxy => browser (XXXXXX)
> HEADERS (stream 1)
> - END_STREAM
> + END_HEADERS
> :status = 5xx (Content Inspection Required)
> content-type = text/html;charset=utf-8
>
> proxy => browser
> DATA (stream 1)
> + END_STREAM
> <body>
> Connection to example.com refused by Content Inspection Gateway
> </body>
>
> proxy => browser
> RST_STREAM (stream 1)
>
> browser => proxy
> HEADERS (stream 3)
> + END_STREAM
> + END_HEADERS
> :method = GET
> :scheme = https
> :path = /
> :authority = example.com
>
> proxy => browser
> ORIGINCERT (stream 3)
>
> HEADERS (stream 3)
> + END_HEADERS
> - END_STREAM
> :status = 200
> content-type = text/html;charset=utf-8
> {other headers]
>
> DATA (stream 3)
> + END_STREAM
> payload
>
There is another use case what that does not
yet solve.
browser: (or user actually)
I want proxy cache pages if I know
that proxy supports https forwarding
and that proxy does certificate checks.
( And I want use tunnel instead if origin
have EV certificate ? )
In that case proxy never does
:status = 5xx (Content Inspection Required)
for CONNECT request.
SETTINGS
TRUSTED_PROXY_CONFIGURED = 1
from browser to proxy does not help.
So proxy needs tells that "I support GET https"
( and proxy needs to cache origin'n certificate
for cached pages so that it can send "ORIGINCERT"
frame. )
But WG is solving that caching problem from
origin server's direction (where
draft-ietf-httpbis-encryption-encoding
is one part of that.)
So it is not easy to decide when do
browser => proxy
HEADERS
+ END_STREAM
+ END_HEADERS
:method = GET
:scheme = https
:path = /
:authority = example.com
/ Kari Hurtta
Received on Friday, 3 March 2017 05:12:13 UTC