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

[Amos Jeffries <[e-mail]>]

On 1/03/2016 1:38 p.m., Mark Nottingham wrote:
> 
>> On 1 Mar 2016, at 11:00 AM, Ted Hardie wrote:
>> 
>> On Mon, Feb 29, 2016 at 3:49 PM, Mark Nottingham wrote:
>> 
>>> 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...

FWIW; The "Accept: */*" header which is already very popular covers all
mime types including this one.

If we are intending this to be used to expose MITM in a clean way. Then
it does need to be spec'd for use on any method even if doing the IETF
thing of 'ignoring' MITM existence in the texts.

Also the worst display related issues are with browsers. Their current
behaviour is to not show anything at all from a CONNECT response
regardle of whether its an error or not.  So backward compatibility
there is already a non-issue - the JSON payload will be silently dropped
by the most problematic clients.

Amos