Re: #552: allow privacy proxies to be conformant

That suggestion did not get much traction.

I did some digging and found that the change I made in [2041]
to address #418 mistakenly changed the original SHOULD NOT to
a MUST NOT. Therefore, the following paragraph will restore the
RFC2616 requirement with the new wording:

   A proxy SHOULD NOT modify header fields that provide information
   about the end points of the communication chain, the resource state,
   or the selected representation (other than the payload) unless the
   field's definition specifically allows such modification or the
   modification is deemed necessary for privacy or security.

Cheers,

....Roy


On Jan 28, 2014, at 5:47 PM, Roy T. Fielding wrote:

> In the IESG comments on p1 from Sean Turner:
> 
>> 1A) s5.7.2 and s2.3: s2.3 mentions privacy proxies and s5.7.2 says the
>> following about proxies without qualifying the type of proxy:
>> 
>>  A proxy MUST NOT modify header fields that provide information about
>>  the end points of the communication chain, the resource state, or the
>>  selected representation.
>> 
>> So does that essentially mean privacy filters proxies are non-conformant?
> 
> http://trac.tools.ietf.org/wg/httpbis/trac/ticket/552
> 
> I think that the above text (which is broader than the specific header
> field requirements in RFC2616) can be improved by replacing it with the
> following text:
> 
>   A proxy MUST NOT modify header fields that provide information about
>   the end points of the communication chain, the resource state, or the
>   selected representation (other than those necessary to describe how
>   the payload has been transformed). However, an exception to this
>   requirement applies to proxies that are specifically configured to
>   remove or filter header fields for the sake of privacy or security.
>   The person or organization selecting the proxy is presumed to have
>   control over its configuration.
> 
> Alternatively, we could go back to the list of specific header fields
> that were specified in RFC2616 sec 13.5.2 and Allow.
> 
> ....Roy
>

Received on Saturday, 1 February 2014 11:17:27 UTC