httpwg / httpbis-issues

1 stars 1 forks source link

allow privacy proxies to be conformant #552

Closed mnot closed 3 years ago

mnot commented 10 years ago

This is exported from #531, in the IESG comments 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?

Reported by fielding@gbiv.com, migrated from https://trac.ietf.org/trac/httpbis/ticket/552

mnot commented 10 years ago

fielding@gbiv.com commented:

I suggest replacing this sentence with the following paragraph:

A proxy MUST NOT modify header fields other than Via, Warning, those identified by Connection, and the fields that describe a transformed payload. 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.

mnot commented 10 years ago

fielding@gbiv.com commented:

Bah, never mind that last suggestion... How about

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.

mnot commented 10 years ago

fielding@gbiv.com commented:

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.

mnot commented 10 years ago

fielding@gbiv.com commented:

From 2613:

Correct a mistake in 2041 regarding the general requirement on a proxy not transforming header fields (was a SHOULD in RFC2616, not a MUST); see #552 and #418

mnot commented 10 years ago
mnot commented 10 years ago

julian.reschke@gmx.de commented:

From 2614:

note change for 2613 (see #552)