W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2016

Re: New Version Notification for draft-nottingham-proxy-explanation-00.txt

From: Mark Nottingham <mnot@mnot.net>
Date: Tue, 1 Mar 2016 10:49:27 +1100
Cc: HTTP WG <ietf-http-wg@w3.org>
Message-Id: <8BD7C79F-6882-43E5-B706-FA3335DBAA73@mnot.net>
To: Ted Hardie <ted.ietf@gmail.com>

> On 1 Mar 2016, at 7:01 AM, Ted Hardie <ted.ietf@gmail.com> wrote:
> 
> Howdy,
> 
> On Sun, Feb 28, 2016 at 5:59 PM, Mark Nottingham <mnot@mnot.net> wrote:
> FYI - would be interested in what people thought, as I know some folks have this problem.
> 
> Pretty (and slightly updated) version at:
>   https://mnot.github.io/I-D/proxy-explanation/
> 
> The document says about the HTML content in a 403 "but browsers are unwilling to show this to end users, since doing so would subject them to a potential man-in-the-middle attack."; this same reluctance seems to me likely to apply to the URL in the proposed JSON structure.  You note the issue considerations section, but seem to come down on the side of including it anyway.  Can you explain more about why? What's the other side of this trade-off look like, in your thinking?

Browsers are unwilling to show HTML because it has the ability to masquerade as the origin; displaying a raw link doesn't, and there's significantly less chance that the user will be confused about that.

Still, it'd be good to have a discussion about whether / when the URL should be displayed. I included it to have that discussion, mostly :)

If we don't include it, I *suspect* it's going to be more difficult to meet some use cases (e.g., get support HERE, complain HERE), and I *suspect* proxies will just put links in the text anyway, to cut-and-paste.


> I found it odd that the document talked about forbidding origin servers from generating the media type, rather than returning it a response.  Below you say it MUST NOT be used with 2xx or 3xx responses; it seems like you could also use similar language for origin server/CDN use.

What's the use case for origin servers generating it?


> The document says that "Clients MAY selectively support this media type. For example, an implementation might deem it only useful (or safe) in CONNECT requests."  Given the other restrictions, I don't use case outside of CONNECT, and I would normally say that you shouldn't send an accept header where you're not willing to receive the type; am I missing some of your thinking here?

Interception proxies.

Cheers,



Mark Nottingham   https://www.mnot.net/
Received on Monday, 29 February 2016 23:49:57 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 22 March 2016 12:47:11 UTC