- From: Mike Bishop <Michael.Bishop@microsoft.com>
- Date: Mon, 20 Jul 2015 09:09:48 +0000
- To: Stefan Eissing <stefan.eissing@greenbytes.de>, Mark Nottingham <mnot@mnot.net>
- CC: HTTP Working Group <ietf-http-wg@w3.org>
Two random thoughts on a quick read-through: Is there value in the client being able to also send the frame, to inform the server what origins it thinks are valid on the connection based on the cert? The server has the option to NACK by sending back a sub-set, rather than waiting until the client makes a request and gets a 421. Easy way to fail fast. Of course, the server can probably presume that the client would send everything in the cert, so it may be moot. The client probably considers the server authoritative for an undefined set based on wildcards in the TLS cert. Depending on the server config, the server may also not have a list of possible wildcard values. The reference to RFC 6454 doesn't permit wildcards, but they seem like they're a necessary value for this use-case. -----Original Message----- From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de] Sent: Monday, July 20, 2015 10:50 AM To: Mark Nottingham <mnot@mnot.net> Cc: HTTP Working Group <ietf-http-wg@w3.org> Subject: Re: New Version Notification for draft-nottingham-httpbis-origin-frame-00.txt Ok, sounds easy to do and helpful for clients. Nit-picking: - if a server wants to indicate that it does not offer/allow any other origin on the current connection, can it send an empty frame or does it always have to include the SNI from the TLS connection? - clients need to be prepared to get a 421 anyway (robustness) - on a h2c connection, this could advise clients to re-use connections only for a set of origins. maybe a server preference for load balancing. (yeah, which clients?) //Stefan > Am 20.07.2015 um 10:06 schrieb Mark Nottingham <mnot@mnot.net>: > > FYI. If people are interested and we have time, can discuss at the end of the WG meeting, or in the hallways. > > Cheers, > > >> Begin forwarded message: >> >> From: internet-drafts@ietf.org >> Subject: New Version Notification for >> draft-nottingham-httpbis-origin-frame-00.txt >> Date: 20 July 2015 10:04:11 am GMT+2 >> To: "Mark Nottingham" <mnot@mnot.net>, "Erik Nygren" >> <nygren@akamai.com>, "Erik Nygren" <nygren@akamai.com>, "Mark >> Nottingham" <mnot@mnot.net> >> >> >> A new version of I-D, draft-nottingham-httpbis-origin-frame-00.txt >> has been successfully submitted by Mark Nottingham and posted to the >> IETF repository. >> >> Name: draft-nottingham-httpbis-origin-frame >> Revision: 00 >> Title: The ORIGIN HTTP/2 Frame >> Document date: 2015-07-20 >> Group: Individual Submission >> Pages: 4 >> URL: https://www.ietf.org/internet-drafts/draft-nottingham-httpbis-origin-frame-00.txt >> Status: https://datatracker.ietf.org/doc/draft-nottingham-httpbis-origin-frame/ >> Htmlized: https://tools.ietf.org/html/draft-nottingham-httpbis-origin-frame-00 >> >> >> Abstract: >> This document specifies the ORIGIN frame for HTTP/2, to indicate >> what origins are available on a given connection. >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> > > -- > Mark Nottingham https://www.mnot.net/ > > > > > <green/>bytes GmbH Hafenweg 16, 48155 Münster, Germany Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
Received on Monday, 20 July 2015 09:10:19 UTC