- From: Mark Nottingham <mnot@mnot.net>
- Date: Thu, 20 Dec 2018 12:56:35 +1100
- To: Ben Campbell <ben@nostrum.com>
- Cc: The IESG <iesg@ietf.org>, draft-ietf-httpbis-cdn-loop@ietf.org, Patrick McManus <mcmanus@ducksong.com>, Tommy Pauly <tpauly@apple.com>, httpbis-chairs@ietf.org, ietf-http-wg@w3.org
Hi Ben, > On 20 Dec 2018, at 10:58 am, Ben Campbell <ben@nostrum.com> wrote: > > *** Substantive Comments *** > > I agree with Alissa's comments, and Adam's comments about configurations that > intentionally cross a CDN more than once. > > - abstract: The abstract could use some more meat. What does the new header > accomplish? I think these are all addressed now. > §2: > -- first paragraph: Seems like this header helps "detect" loops, rather than > "prevent" them. Good point. I've changed "prevent" to "detect" throughout -- including in the document title. > -- 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? > §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. > ** Editorial Comments *** > > §1, > -- 4th paragraph: "loops between multiple CDNs be used as an > attack vector" Missing word(s) around "CDNs be"? Fixed, thanks. > -- last paragraph: The last sentence os convoluted. Can it be broken into > simpler sentences? I've rewritten to: """ This specification defines the CDN-Loop HTTP request header field to help prevent such attacks and accidents among implementing forwarding CDNs, by disallowing its modification by their customers. """ Cheers, -- Mark Nottingham https://www.mnot.net/
Received on Thursday, 20 December 2018 01:57:05 UTC