- From: Cory Benfield <cory@lukasa.co.uk>
- Date: Fri, 10 Jul 2015 20:39:30 +0100
- To: Amos Jeffries <squid3@treenet.co.nz>
- Cc: ietf-http-wg@w3.org
> On 10 Jul 2015, at 19:05, Amos Jeffries <squid3@treenet.co.nz> wrote: > > On 11/07/2015 2:12 a.m., Stefan Eissing wrote: >> >> A bit more thinking: this whole server-side creation can only work when >> there are *no* concentrating intermediates involved, right? Where would a >> proxy forward the server stream to? > > Any client who both advertised willingness to be a server and had the > right :authority. So this is a good idea. However, this raises an important question: how do we trust a client that asserts validity for a specific :authority? There’s a risk here of being able to ‘intercept’ messages by asserting that I’m a valid destination for an :authority that some other client is also using. It might be that we think this is OK: HTTP/2 P2P is likely to be used only in a trusted environment. Alternatively, we could come up with some other requirement: for example, the client might need to provide a TLS client certificate that is valid for the :authority it is asserting. Ideas would be valuable here. >> Otherwise clients would need to allocate some sort of name at proxies >> and then proxies need to inspect new HEADERs for matching :authority and >> it gets only uglier from there... >> > > Yep. Certainly gets nasty. Not impossible, just really nasty. > > I can forsee some error status being used a lot to reject > server-initiated requests to clients who disappeared already. This feels like a good addition. Got a name you feel like using? Cory
Received on Friday, 10 July 2015 19:40:02 UTC