The wmflabs.org domain is deprecated. We will keep it working indefinitely because that is a relatively low burden. This means that tools-static.wmflabs.org should also be considered "safe" to use today, but it would be less confusing for new users to see the wmcloud.org or toolforge.org domains being used for the static content hosting service in documentation and tutorials.
Description
Description
Related Objects
Related Objects
Event Timeline
Comment Actions
The static tool at https://static.toolforge.org/ hosts a small amount of legacy static content today. Per toolviews there is a minimal amount of traffic handled by this tool; request volume is on the order of 20-40 requests per day. It seems like it would be possible to usurp this tool and use its hostname as the canonical hostname replacing tools-static.wmflabs.org. The tool's existing static content could be hosted by the shared static server, possibly with some redirects added to the nginx config so that https://static.toolforge.org/res/ redirects to https://static.toolforge.org/static/res/ with the legacy tool's on-disk files moved to $HOME/web/static/ and $HOME/web/static/res/ as appropriate.
Comment Actions
Would a scheme like $TOOL.static.toolforge.org provide the desired in-browser separation or would we need $TOOL.$SOMETHING.$TLD to get good results?
Comment Actions
I personally think $TOOL.static.toolforge.org would be good enough given its only static things.
The main thing $TOOL.$SOMETHING.$TLD gets you is slightly better cookie separation, better csrf protection, and better cache partitioning. None of that seems particularly relavent to a static content host.
Even just doing subdomains is a bit on the paranoid side, i just think it would be nice if its being moved anyways and its not very much extra work. It would mostly help in the edge case where someone is hosting an entirely client side web app on the static host. However that is definitely an edge case so this only makes sense if its being moved anyways and the extra effort is minimal.
Comment Actions
I've secretly been hoping that the current iteration of tools-static would go away at some point in favour of some object storage based service.
Comment Actions
That would at least require allowing Toolforge tools to use the object storage service at all (T358496: [toolforge,storage] Provide per-tool access to cloud-vps object storage). That would then need to be followed by an information campaign to drive migration to the new service. I generally agree that would be a nice long term solution.
Messing with the existing tools-static.wmflabs.org nginx config and adding some records to DNS seems like something that could happen on a shorter timeline, but like many of our ideas for incremental improvement it will need someone to make time to make it happen.