Subject: Re:Quick feedback on draft-nottingham-web-proxy-desc-00

From: "Smith, Kevin, (R&D) Vodafone Group" <[email-masked]>
Date: Thu, 2 Oct 2014 13:33:07 +0000

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.

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.

Overall a very welcome proposal, cheers!
Kevin

---

From: Julian Reschke <[email-masked]>
Date: Thu, 02 Oct 2014 18:02:25 +0200

> ..the MUST leaves no room for user choice to override the server decision.

Rightfully. This is what RFC 7230 already requires.

> ...

Best regards, Julian

---

From: "Smith, Kevin, (R&D) Vodafone Group" <[email-masked]>
Date: Thu, 2 Oct 2014 16:20:02 +0000

>> Rightfully. This is what RFC 7230 already requires.

Why rightfully, though? The example given has merit, and could make the difference between a functional user experience, and not.

Ideally the content server would be providing a response that was suitable for the delivery context, in which case no-transform should indeed be ignored, but that's not always the case in practice. Hence the point about allowing the user to choose.

Cheers
Kevin

---

From: Roland Zink <[email-masked]>
Date: Thu, 02 Oct 2014 18:34:03 +0200

I think this didn't changed since RFC 2616 already says:

14.9.5 No-Transform Directive

    no-transform
       Implementors of intermediate caches (proxies) have found it useful
       to convert the media type of certain entity bodies. A non-
       transparent proxy might, for example, convert between image
       formats in order to save cache space or to reduce the amount of
       traffic on a slow link.

       Serious operational problems occur, however, when these
       transformations are applied to entity bodies intended for certain
       kinds of applications. For example, applications for medical
       imaging, scientific data analysis and those using end-to-end
       authentication, all depend on receiving an entity body that is bit
       for bit identical to the original entity-body.

       Therefore, if a message includes the no-transform directive, an
       intermediate cache or proxy MUST NOT change those headers that are
       listed in section 13.5.2 as being subject to the no-transform
       directive. This implies that the cache or proxy MUST NOT change
       any aspect of the entity-body that is specified by these headers,
       including the value of the entity-body itself.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 02 Oct 2014 19:57:47 +0200

> Ideally the content server would be providing a response that was suitable for the delivery context, in which case no-transform should indeed be ignored, but that's not always the case in practice.…

The HTTP spec is the basis here, and it says what it says. No new spec 
that doesn't update/obsolete the base spec can change that.

Are you proposing a change to the base spec?

Best regards, Julian

---

From: "Martin Nilsson" <[email-masked]>
Date: Fri, 03 Oct 2014 02:20:21 +0200

On Thu, 02 Oct 2014 18:20:02 +0200, Smith, Kevin, (R&D) Vodafone Group  
<[email-masked]> wrote:

> Why rightfully, though? The example given has merit, and could make the  
> difference between a functional user experience, and not.

There are two relevant failure modes here. Something breaks because a  
proxy did something, or something breaks because the proxy didn't do  
something. The spec currently favors the second one, which arguably makes  
debugging simpler and failures easier to reproduce across different  
networks. E.g. instead of correcting PNG images with the old palette  
buffer overrun bug, you should block the delivery.

It would however have been good if the client was also part of this  
decision. E.g. sending no-transform or do-transform in the request. Also,  
I have yet to see a legitimate use for no-transform in a real world  
application.

/Martin Nilsson

-- 
Using Opera's mail client: http://www.opera.com/mail/

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 7 Oct 2014 18:15:16 +1100

> ..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.

> 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 alwa…

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!

Thanks!

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