- From: Amos Jeffries <squid3@treenet.co.nz>
- Date: Tue, 1 Mar 2016 15:52:24 +1300
- To: ietf-http-wg@w3.org
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
Received on Tuesday, 1 March 2016 02:53:01 UTC