- From: Willy Tarreau <w@1wt.eu>
- Date: Mon, 26 Aug 2013 08:42:24 +0200
- To: Roberto Peon <grmocg@gmail.com>
- Cc: Salvatore Loreto <salvatore.loreto@ericsson.com>, HTTP Working Group <ietf-http-wg@w3.org>
On Sun, Aug 25, 2013 at 11:25:01PM -0700, Roberto Peon wrote: > I'm all for people working out how to do explicit proxy configuration. > I am pro-proxy, so long as the customers want proxies and are able to > exercise choice about it. > I do believe, however, that we could do substantially better w.r.t. caching > than we do today-- I just don't have the bandwidth to deal with that and > this effort simultaneously. :) > > In any case, I suspect that the entirety of the complexity here comes down > to a MAYs and two MUSTs, for instance: > > An HTTP/2 client MAY send resources with an HTTP scheme down an encrypted > connection at any time. > An HTTP/2 server MAY choose not to process such a request, however if it > chooses to refuse such a request it MUST respond with (new) error code XXX > - scheme unsupported on connection, which indicates that the request was > not processed and is safe to retry on an unencrypted connection. I'm generally fine with this principle. I'd rather have at least two codes, one being "not supported for this resource" and the other one being "not implemented on this host". With the principle above, we could accelerate https adoption (more transparent since there's no URL changes), let users decide if they prefer fast connections or default encryption, and still have CDNs and porn sites continue to work fast since we must not forget they're the ones that fill the internet pipes all over the world. Willy
Received on Monday, 26 August 2013 06:42:49 UTC