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 11:38:59 +1100
Cc: HTTP WG <ietf-http-wg@w3.org>
Message-Id: <0817613D-A09F-4FE3-B4D5-B78749D015B2@mnot.net>
To: Ted Hardie <ted.ietf@gmail.com>

> On 1 Mar 2016, at 11:00 AM, Ted Hardie <ted.ietf@gmail.com> wrote:
> On Mon, Feb 29, 2016 at 3:49 PM, Mark Nottingham <mnot@mnot.net> wrote:
> >
> >
> > 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.
> That kind of indicates that there may be a need for more than one URI, so having a single "moreinfo" URI may not help avoid the cut-and-paste.  I kind of suspect that the best thing to do is to provide the facility for bare URIs in text, and ruthlessly suppress any ability to use anchor text to hide what's in the URI.   That remains a bit of risk, but might be the best balance.

I think one link is good -- any additional information including other links can be found at the other end of it. The important thing is to give the user a solid clue that this communication is NOT from the origin they were making the request to; once they know that and follow a link -- which has a different origin -- the context is relatively clear.

> > 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?
> I don't have a use case for that, I was commenting on the oddity of preventing them from generating it, rather than saying that MUST NOT return it in a response (or even use it, as you say for 2xx and 3xx responses).  I am perfectly willing to save my paint for other bikesheds, though.

"generate" is specific terminology for HTTP -- see <http://httpwg.org/specs/rfc7230.html#conformance>. I may not have used it consistently here (or indeed, even generated it consistently).

> > 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.
> So, a client should send this accept request with all queries in case there is a friendly enough man in the middle to tell them that the traffic is being prevented and why?  I can't picture that being the right trade-off, personally, but I'd be interested in whether this sounds plausible to other folk.

Yeah, I doubt it too. It could be that we end up specifying it just for CONNECT.

I wanted to get an indication of implementer interest before I went too far into tweaking it, though...


Mark Nottingham   https://www.mnot.net/
Received on Tuesday, 1 March 2016 00:39:29 UTC

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