- From: Kari Hurtta <hurtta-ietf@elmme-mailer.org>
- Date: Wed, 02 Mar 2016 16:19:37 +0000
- To: Thomas Mangin <thomas.mangin@exa-networks.co.uk>
- Cc: Mark Nottingham <mnot@mnot.net>, HTTP WG <ietf-http-wg@w3.org>, Amos Jeffries <squid3@treenet.co.nz>, Kari Hurtta <hurtta-ietf@elmme-mailer.org>
Thomas Mangin <thomas.mangin@exa-networks.co.uk>: (Wed Mar 2 11:25:06 2016) > could be used by another non-configured proxy down the line. This could > be mitigated by mandating a draft aware proxy to block any > json+explaination response messages coming back towards the client. If proxy receices application/proxy-explanation+json from upstream proxy, that is directed to that proxy. Proxy can use use it to form it's own error report to downstream (either text/html or application/proxy-explanation+json) If proxy receices application/proxy-explanation+json from origin server then it is another error case. Yes, in any case application/proxy-explanation+json is consumed and not passed to downstream. So I see that media type to be connection releated. ( But as I noticed earlier, that new header field is perhaps overengineering here. ) >> Register new header field for that nonce. >> >> Browser may include that on request when it is using proxy: >> >> New-header-field: nonce-value >> Connection: new-header-field >> >> Connection header field prevents origin server seeing >> this (if proxy follows HTTP/1.1 -- I do not know how >> this play with HTTP/2, but HTTP/2 is likely to be used >> only with encrypted connections / with CONNECT method. ) >> >> Given nonce-value can be included to >> application/proxy-explanation+json >> as own member. >> >> ( Header field name should be something short like >> 'proxy-nonce', I think. ) >> ( I notice that also this new nonce header field ('proxy-nonce' for >> example) >> may work as indicator that application/proxy-explanation+json is >> supported >> by browser. ) / Kari Hurtta
Received on Wednesday, 2 March 2016 16:38:20 UTC