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

[Kari Hurtta <[e-mail]>]

Thomas Mangin <[e-mail]>: (Wed Mar  2 11:25:06 2016)
> If used with the CONNECT verb, there is no risk of the header carrying 
> this information to be be passed on to the origin. However, if allowed 
> through HTTP, any header would pass through towards the origin and then 
> 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.

That is why I put it to Connection: -header field.

>> 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. )

I think that browser will quite fast learn
that is proxy supporting HTTP/1.1

Simple use this only when there is seen HTTP/1.1
response from proxy for some previous request.

If proxy wants use this, then it is better to support
HTTP/1.1

https://tools.ietf.org/html/rfc7230#section-6.1

|   When a header field aside from Connection is used to supply control
|   information for or about the current connection, the sender MUST list
|   the corresponding field-name within the Connection header field.  A
|   proxy or gateway MUST parse a received Connection header field before
|   a message is forwarded and, for each connection-option in this field,
|   remove any header field(s) from the message with the same name as the
|   connection-option, and then remove the Connection header field itself
|   (or replace it with the intermediary's own connection options for the
|   forwarded message).

/ Kari Hurtta