- From: Mark Nottingham <mnot@mnot.net>
- Date: Tue, 7 Oct 2014 18:15:16 +1100
- To: "Smith, Kevin, (R&D) Vodafone Group" <Kevin.Smith@vodafone.com>
- Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
On 2 Oct 2014, at 11:33 pm, Smith, Kevin, (R&D) Vodafone Group <Kevin.Smith@vodafone.com> wrote: > Introduction, p3 > "Proxies should always respect the wishes of the end user and Web site, and" > > These could be in conflict - for example, the Web site does not wish to have its content transformed by a proxy, but the user may be on a poor connection that requires the response to account for that. This also affects section2: > > "[RFC7230] Section 5.7.2 requires proxies to honour the semantic of the "no-transform" cache-control directive, [...], WPD proxies MUST honour these requirements." > > ..the MUST leaves no room for user choice to override the server decision. I think Julian has already answered sufficiently here. HTTP -- like all protocols -- is an agreement between parties, and we can't retroactively change the semantics of that agreement to benefit one party at the expense of another. In this way it's very similar to the end-to-end security of HTTPS URLs; we can't retroactively allow a third party to interpose themselves, as this would be surprising and break that agreement. > Section 3.6: > " If the string "CONNECT" appears in alwaysDirect, it indicates that > requests that require establishment of a tunnel (e.g., for "https" > URLs) MUST NOT use the WPD's proxies, but instead ought to be made > directly to the origin (i.e., without a tunnel)." > > IIRC CONNECT involves the proxy in the setup of the tunnel, in which case 'MUST NOT use the WPD's proxies' seems misleading. If the intention is that the request is that tunnelled requests are always direct, then maybe 'TUNNELLED' is a more appropriate value. Sounds reasonable... I'm going to try to get a new version out soon, in the meantime, I've recorded at <https://github.com/mnot/I-D/issues/69>. > Overall a very welcome proposal, cheers! > Kevin Thanks! -- Mark Nottingham https://www.mnot.net/
Received on Tuesday, 7 October 2014 07:15:45 UTC