- From: Salvatore Loreto <salvatore.loreto@ericsson.com>
- Date: Wed, 16 Oct 2013 18:17:27 +0000
- To: Nicolas Mailhot <nicolas.mailhot@laposte.net>
- CC: HTTP Working Group <ietf-http-wg@w3.org>
Hi Nicolas thanks for the comments see more inside br /Salvatore On Oct 9, 2013, at 3:01 PM, Nicolas Mailhot <nicolas.mailhot@laposte.net> wrote: > > Le Mer 9 octobre 2013 06:03, Salvatore Loreto a écrit : >> Hi there, > > Hi > >> we have just submitted a draft draft >> that advocates the importance and the benefits that proxies can provide >> for HTTP/2.0 >> and aims to start a discussion on this topic within the HTTPBis wg > > Thank you for this draft > > I fear the terminology does not quite cover one of the most common > use-case for intermediaries right now, which is security/caching > intermediaries. well we explicitly stated in the draft that in this initial version we have not considered caching. We recognise that it is an important part of the all web architecture and that it should stay in 2.0 as well as plain HTTP > This use case is present in Enterprise gateways and but > also more and more on end-user systems (either via built-in browser > functionalities of via extensions like ad block plus which are > semantically a security proxy that happens to be deployed on the same > system). > > Unlike a transforming proxy a security intermediary/caching does not aim > to transform messages in any semantic way. The intent is to relay as much > stuff unchanged as possible. good point! > > However, unlike a tunnel proxy a security/caching intermediary is party to > the http connexion because it may block some elements for security > reasons, we tried to include this aspect in the draft, but if you think is not maybe we have to make more explicitly > or relay elements that still exist in its cache but have been > changed server-side. not sure why it should server a staled content? > > Also, it does need to convey its actions (typically, why some element has > been blocked or how to unblock by authenticating for example) to > endpoints. And it does not want at all for this communication to > masquerade as something else. that is a good point, the user should become always aware of any changes made by a proxy > > I think one of the root reasons proxies does not work correctly now is > this erroneous terminology. People want to think about them as transparent > tunnels (which they are not), and when they diverge from transparent > tunnels they complain about transformations (which is *not* the intent at > all, the few transformations that do occur only exist to simulate the > communication channel that security/caching gateways need and which has > been completely forgotten in http specs) yes terminology is part of the problem for sure > Making this use case explicit in the specs and fixing the intermediary > communication problem would go a long way to remove proxies as a hate > object. > > -- > Nicolas Mailhot > > >
Received on Wednesday, 16 October 2013 18:17:52 UTC