RE: Framing the proxy discussion: does HTTP2 come with new proxy mechanism ?

Hi Mark

> ## Proxies and HTTP/2
> 
> I've also seen a few people refer to "doing something about proxies in HTTP/2."
> 
> To be clear -- there is nothing in HTTP/2 that is fundamentally different for proxies, and our charter for that effort makes introducing 
> new proxy mechanisms that are specifically bound to HTTP/2 unlikely. 

It is true that there is nothing about proxy in the HTTPbis charter. It does not mean that HTTP2 does not introduce new proxy mechanism. IMO, the connection management of HTTP2 where resources of multiple domains and of multiples schemes are multiplexed in a single connection is a new proxy mechanism.

> 
> People are still welcome to make proposals regarding proxies in HTTP/2, but realise that the bar for getting them in will be quite high, 
> both because of the charter and where we're at in our schedule. Discussing proxies *in general* (i.e. as applicable to /2 as well as /1), OTOH, is fine.

H1 proxies interop with the Internet and the local networks because they rely on standard and defacto standards like proxy.pac and WPAD. To lower the bar for HTTP2 proxy we have to base on solutions which are running and adapt them, even deeply.

> Likewise, HTTP/2 does *not* require encryption. While we understand that prevalence of encryption is increasing, and some implementers
>  are making choices about how they deploy HTTP/2 that affect this, it doesn't follow that HTTP/2 and encryption are intrinsically bound, 
> or that we "*have* to do something about it in HTTP/2."

It is true that HTTP/2 and encryption are not intrinsically bound. Nevertheless, IMO, the HTTPbis WG must specify how current HTTP proxies are going to move to HTTP2 and to support content integrity?

We based HTTP2 works on SPDY. Toronto meeting is a unique opportunity to focus on the new proxy mechanisms it introduces.

Cheers
Emile

 
-----Original Message-----
From: Mark Nottingham [mailto:mnot@mnot.net] 
Sent: lundi 23 juin 2014 10:21
To: HTTP Working Group
Subject: Framing the proxy discussion

Everyone,

The proxy discussion is active once again. Please pay attention to the points below in order to make it more productive:


## Catching Up

I see we have had a number of people who are fairly new to the working group (or perhaps just newly active) join the discussion. 

Welcome! Please remember that this mailing list has a very large distribution, and that its primary focus is the identified work items of the group -- which proxies are not *yet* included within. As such, please take the time to read the archives of the mailing list, as well as the working documents, so that you can avoid repeating arguments that have already been made (which is starting to happen).

Here are a few handy links to get you started:
  * http://lists.w3.org/Archives/Public/ietf-http-wg/
  * https://github.com/http2/http2-spec/wiki/Proxy-User-Stories
  * http://tools.ietf.org/html/draft-nottingham-http-proxy-problem
  * http://tools.ietf.org/html/draft-loreto-httpbis-explicitly-auth-proxy
  * https://github.com/httpwg/wg-materials/blob/master/interim-14-03/minutes.md#proxies

Also, a gentle reminder - we make decisions based upon technical arguments ("rough consensus and running code"), not voting. So repeating an argument or "+1-ing" it only adds to noise, it doesn't help your case. Please have a read of <http://tools.ietf.org/html/draft-resnick-on-consensus> if this is new to you.


## Proxies and HTTP/2

I've also seen a few people refer to "doing something about proxies in HTTP/2."

To be clear -- there is nothing in HTTP/2 that is fundamentally different for proxies, and our charter for that effort makes introducing new proxy mechanisms that are specifically bound to HTTP/2 unlikely. 

People are still welcome to make proposals regarding proxies in HTTP/2, but realise that the bar for getting them in will be quite high, both because of the charter and where we're at in our schedule. Discussing proxies *in general* (i.e. as applicable to /2 as well as /1), OTOH, is fine.

Likewise, HTTP/2 does *not* require encryption. While we understand that prevalence of encryption is increasing, and some implementers are making choices about how they deploy HTTP/2 that affect this, it doesn't follow that HTTP/2 and encryption are intrinsically bound, or that we "*have* to do something about it in HTTP/2."


## "Split Browsers"

For *now*, I do not consider "split browsers" in-scope for this Working Group; we cannot control the details of a protocol when it's not HTTP, as this effectively is. I realise that they have a potentially huge impact upon the landscape, but this is **not** the "everything to do with the Web" Working Group. We have more than enough on our plate as it is.

Note that this doesn't mean that discussing "split browsers" is completely verboten; I just don't want them to overshadow other considerations. Please moderate yourselves.


## Toronto

We're currently scheduled for two sessions in Toronto, and I'm planning to devote a significant chunk of one of them to discussing proxies. 

We'll specifically be talking about the proxy-problem draft as well as the proxy user stories; beyond that, we'll talk about what other work items we might attempt. If you would like to suggest a particular topic or make a presentation, please contact me privately.

Please moderate your expectations for this discussion; while we might agree to start work on some exploratory documents (such as proxy-problem), it's unlikely we'll come out with more substantial work items in progress right at the end of this meeting.

Our charter requires Barry and I to agree to new work; from my perspective, I want to see consensus to add a work item and a clear path to achieving its success, which means both broad implementation and successfully navigating the security and privacy requirements of the IETF. We also have to consider what's appropriate for this WG to attempt, and what's best left to other venues.

Given that, the nature of this work and how many different communities it touches, it's unlikely we'll have a good sense of that in the short time we have together this time. However, we can continue the discussion and try to find common ground on how to improve HTTP's handling of proxies.

Thanks for reading this far,

--
Mark Nottingham   https://www.mnot.net/






_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

Received on Monday, 23 June 2014 11:19:10 UTC