You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
CDN determines the asset type based on the URL, possibly using a file extension
CDN invokes an AssetHandler (for example handlers/image.js). If the URL has no file extension, handlers/default.js is used.
the AssetHandler instantiates a StorageHandler, based on the CDN configuration. For example, if the AssetHandler is an ImageHandler, CDN obtains the storage type from the "images" section of the configuration file.
the AssetHandler calls the StorageHandler's get() method to attempt to retrieve the file
This flow is awkward and cumbersome, and we have to make a lot of assumptions about files that we really shouldn't be making. For example in the past we assumed if no extension was in the URL then the ImageHandler should be forced to respond to the request as if it was a JPG. That "feature" was removed so that we can handle URLs that are requesting HTML pages from a configured remote endpoint, allowing passthrough HTML caching for requests such as https://dadi.cloud/en/team <-- no extension and certainly not forceable into a JPG.
The correct way to handle the above may be to invoke the StorageHandler first,
retrieve the file, determine the content-type of the response and only then determine which AssetHandler should be used. One benefit of this approach is that we can fail fast if the file cannot be found.
However there may be a case where this approach doesn't work. Another discussion in progress is how we actually configure CDN's locations of assets and images. It'd be great to allow configuration of locations on a mime type basis, in which case for known mime types (i.e. URLs containing an extension) we'd be able to instantiate a StorageHandler using the appropriate configuration for that mime type. How we handle this for extension-less URLs still remains a question...
The request flow in CDN is currently:
handlers/image.js
). If the URL has no file extension,handlers/default.js
is used.get()
method to attempt to retrieve the fileThis flow is awkward and cumbersome, and we have to make a lot of assumptions about files that we really shouldn't be making. For example in the past we assumed if no extension was in the URL then the ImageHandler should be forced to respond to the request as if it was a JPG. That "feature" was removed so that we can handle URLs that are requesting HTML pages from a configured remote endpoint, allowing passthrough HTML caching for requests such as https://dadi.cloud/en/team <-- no extension and certainly not forceable into a JPG.
The correct way to handle the above may be to invoke the StorageHandler first,
retrieve the file, determine the content-type of the response and only then determine which AssetHandler should be used. One benefit of this approach is that we can fail fast if the file cannot be found.
However there may be a case where this approach doesn't work. Another discussion in progress is how we actually configure CDN's locations of assets and images. It'd be great to allow configuration of locations on a mime type basis, in which case for known mime types (i.e. URLs containing an extension) we'd be able to instantiate a StorageHandler using the appropriate configuration for that mime type. How we handle this for extension-less URLs still remains a question...
Issues possibly involved: #349, #351, #437
The text was updated successfully, but these errors were encountered: