- From: Kari Hurtta <hurtta-ietf@elmme-mailer.org>
- Date: Thu, 2 Mar 2017 07:14:14 +0200 (EET)
- To: Mike Bishop <Michael.Bishop@microsoft.com>
- CC: Kari Hurtta <hurtta-ietf@elmme-mailer.org>, Alex Rousskov <rousskov@measurement-factory.com>, Willy Tarreau <w@1wt.eu>, HTTP working group mailing list <ietf-http-wg@w3.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.)
>
>
http://httpwg.org/specs/rfc7540.html
| Sending or receiving a HEADERS frame causes the stream to become "open". The stream
| identifier is selected as described in Section 5.1.1. The same HEADERS frame can also
| cause a stream to immediately become "half-closed".
My reading is:
It is HEADERS frame for browser to proxy which opens stream, not
HEADERS frame on proxy's response from proxy to browser.
1) From browser to proxy
HEADERS
+ END_STREAM
+ END_HEADERS
:method = GET
:scheme = https
:path = /
:authority = example.com
2) From proxy to browser
"Origin certificate"
HEADERS
+ END_HEADERS
- END_STREAM
:status = 200
content-type = text/html;charset=utf-8
{other headers]
DATA
+ END_STREAM
payload
----
> Alex Rousskov <rousskov@measurement-factory.com<mailto:rousskov@measurement-factory.com>>
>
> https://lists.w3.org/Archives/Public/ietf-http-wg/2017JanMar/0377.html
>
>
>
> > To be more precise, the _browser_ needs that, but, yes, this is
>
> > probably required, and that is exactly why I mentioned secure response
>
> > signing (or something like that) as a prerequisite. The proxy would
>
> > need to somehow forward origin's response signature or public
>
> > certificate (at least). This is where an HTTP extension is required.
>
> > Everything else is already supported (at the protocol level) AFAICT.
>
>
>
> If HTTP/2 can be assumed for that https connection from browser to proxy, the that extension can be new HTTP/2 frame. I think that this fits to that place.
>
>
>
> Proxy sends that frame to browser before responses HEADERS frame.
>
>
>
> This allows browser only show status after the fact. Browser can not examine origin's certificate before it sends to proxy
>
>
>
> HEADERS
>
> + END_STREAM
>
> + END_HEADERS
>
> :method = GET
>
> :scheme = https
>
> :path = /
>
> :authority = example.com
/ Kari Hurtta
Received on Thursday, 2 March 2017 05:15:40 UTC