Retrieving the outputs of a release

What a release holds#

Preparation stores outputs. One public module usually carries more than one: its JavaScript, the stylesheet it declares and its external source map are three outputs with three media types and three sets of bytes, under one module identity. A package also carries assets, such as images and fonts, and a release generates documents of its own, such as its HTML shell and its resolution document.

Each stored output is an artifact with a content digest, a media type and a size. Two things name it and they are not the same value:

The same identity can hold different bytes in another dependency context, and the same bytes can answer more than one identity — an alias of a package from another registry, or one module reached through two targets. The list reports both, so neither is mistaken for the other.

The inventory and the outputs are different lists#

The inventory is what the application reaches: one row per module, stylesheet or asset the analysis traced, with the state of that item. The outputs are what processing produced and stored for those items, which is more rows and different columns. A person reading a release needs both: the inventory says whether everything needed is there, the outputs say what is there and how to retrieve it.

Operations#

releases.outputs takes family (module, style, map, asset or document), after and limit. Its counts describe the whole release, not the page: how many outputs it holds, how many stored bytes they occupy counted once per artifact, how many need authorization and how many identities the shared public origin serves.

A release that has not frozen its outputs answers STATE_INVALID, not an empty list: a release that produced nothing yet and a release that produced nothing are different answers.

Three places, and they are not interchangeable#

Every output reports where it can be retrieved.

The shared origin serves public identities, so an output of a private application and a restricted source map never appear there. Reading this list retrieves no bytes, and no retrieval of any kind creates compilation work: a miss is an answer, never a build.

Retrieving one output before the application has an address#

releases.output is the path that needs no application host. It reads the store and answers the bytes with the media type they were stored under, their size and a strong "sha256-…" validator; If-None-Match answers 304, and HEAD answers the same description without a body. A recorded output whose bytes the store cannot read is UNAVAILABLE, never a miss.

It is a management origin, which holds the session of the person reading it, so it never lets a browser run what it stores:

• Content-Disposition: attachment, so a navigation downloads instead of rendering;
• X-Content-Type-Options: nosniff, so the type is the recorded one and not a guess;
• Content-Security-Policy: default-src 'none'; sandbox, so a stored HTML shell or script has no powers of this origin;
• Cache-Control: no-store and Vary: Cookie, because the answer depends on who asked.

The CDN administration application uses this path for its Outputs panel: it retrieves the bytes, shows text as text and an image as an image under its recorded type, and offers the copy it already holds as a download. It never navigates to the address of an output.

Errors#