Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#552 closed design (incorporated)

allow privacy proxies to be conformant

Reported by: fielding@… Owned by: draft-ietf-httpbis-p1-messaging@…
Priority: normal Milestone: 26
Component: p1-messaging Severity: In IESG Evaluation
Keywords: transform, proxy, privacy Cc:

Description

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?

Change History (6)

comment:1 Changed 6 years ago by fielding@…

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.

comment:2 Changed 6 years ago by fielding@…

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.

comment:3 Changed 6 years ago by fielding@…

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.

comment:4 Changed 6 years ago by fielding@…

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

comment:5 Changed 6 years ago by fielding@…

  • Resolution set to incorporated
  • Status changed from new to closed

comment:6 Changed 6 years ago by julian.reschke@…

From [2614]:

note change for [2613] (see #552)

Note: See TracTickets for help on using tickets.