Summary

  • A 27 October revision of the IETF CDNI edge-control draft spells out a cache trap: an upstream origin allow-list can be checked correctly, yet a wildcard CORS response may be reused for an excluded origin if the shared cache mishandles Vary.
  • The proposal also states where the control actually sits: CORS headers govern a conforming browser’s exposure of a response to script; the downstream CDN still serves the public resource.

Imagine a venue with a guest list. The doorman admits one visitor and hands over a gold wristband. The coat-check machine then photocopies that band for somebody who was never on the list. Both desks followed their own local routine; the admission decision was lost between them. A new revision of the IETF CDNI edge metadata draft describes the network equivalent, using an origin allow-list, a wildcard CORS header and a shared cache.

An upstream CDN can send MI.CrossoriginPolicy through the CDNI Metadata Interface defined in RFC 8006. The downstream CDN uses the policy to compare a browser request’s Origin with an allow-list. With wildcard-return enabled, a match can receive Access-Control-Allow-Origin: *; a nonmatch receives no CORS response header. The asterisk is not a public roll call of who matched. It is a badge on the response, meant for the browser that made that particular request.

That detail makes caching an authority problem. A response bearing * does not itself record which origin passed the check. If a shared cache serves it to another origin without varying on the origin-dependent request headers, that second browser can receive a wildcard header even though its origin was absent from the allow-list. Revision -13’s new operational section names this failure. The draft also requires a downstream CDN to generate its CORS headers per response instead of storing them inside the cached representation, and to put the relevant request-header names in Vary.

The previous -12 text described the metadata objects; -13 makes the handoff and its limits harder to miss. It states plainly that CORS is enforced by a conforming user agent when deciding whether to expose a served response to script. The downstream CDN still serves the publicly accessible resource when CORS headers are absent. Requests that use browser credentials mode include fall outside these objects’ scope, because combining CORS with authentication and authorization needs behavior beyond this configuration.

Timing supplies another twist. The upstream CDN may make a resource available before the policy reaches the downstream edge. During that gap, the edge serves the resource without CORS headers; a conforming browser fails its CORS check. The newly added operational section says operators can retrieve the configuration currently in effect using the existing RFC 8006 interface, then compare it with observed behavior. It adds no special new monitoring channel. A configured rule, a delivered rule and a response seen by a browser are three different receipts.

The IETF Datatracker lists revision -13 as a CDNI working-group draft in IESG Evaluation. For the operators sharing delivery, the practical question is immediate: who checks the doorman, the coat-check machine and the wristband that finally leaves the building?