- From: Mark Nottingham <mnot@mnot.net>
- Date: Thu, 20 Dec 2018 15:09:24 +1100
- To: Ben Campbell <ben@nostrum.com>
- Cc: draft-ietf-httpbis-cdn-loop@ietf.org, httpbis-chairs@ietf.org, Patrick McManus <mcmanus@ducksong.com>, The IESG <iesg@ietf.org>, Tommy Pauly <tpauly@apple.com>, ietf-http-wg@w3.org
> On 20 Dec 2018, at 2:22 pm, Ben Campbell <ben@nostrum.com> wrote: >> >>> -- last paragraph: "To be effective, intermediaries - including >>> Content Delivery Networks - MUST NOT remove this header field," >>> >>> Does that put normative requirements on things that do not implement the spec? >> >> That's a good question. If this is an issue, I think we could address it by either updating RFC7231, or removing the requirement and making this prose. >> >> Do people have a preference there? > > I’m okay either way. The latter is probably easier :-) OK. I've taken the easy way out and changed "MUST NOT" to "must not". >>> §3, first paragraph: How can CDNs stop their customer from modifying the header? >> >> That depends on what capabilities that they offer to their customers; if they allow customers to configure a header modification, they'll need to make an exception for this header field name. Doing so is common; e.g., most CDNs don't allow you to modify headers like Connection or Content-Length, because doing so would break HTTP. >> > > Ah, maybe my confusion who the “customer” is and what it means for them to modify headers. If we are talking about customers configuring CDN settings, then it’s pretty obvious. If, OTOH, the “customers” modify headers in a client or intermediary, then things are different. From your response, I gather the former was the intent. I've changed to "For it to function, CDNs cannot allow customers to modify or remove it in their configuration" to try to clarify this. Thanks! -- Mark Nottingham https://www.mnot.net/
Received on Thursday, 20 December 2018 04:09:53 UTC