I have seen this popping up once in a recent flame graph. I think most
services should be designed in a way that they can be instantiated
very quickly and only start doing expensive stuff when we are sure we
really need it. This was not the case here. The file domains.php is
about 150,000 lines long and can take several 100ms to load in the
worst case.
Bug: T200758
Change-Id: I7c0c787230e8cff40e8e73fede0ac1dce63ea1ca
The benchLookup.php shows that the lookups take half the time as before,
without more memory
In the lookup use offsets instead of preg_replace to create the smaller
strings, also simplify the return
In the hook handler use str_starts_with to check start of string,
strpos needs to scan the whole string for a negative check,
but we need only need information about the begin
Bug: T316443
Change-Id: Ibc0cbe5f7f14bd56d4e126fa7ed183a807d9a99c
* Turn HSTSPreloadLookup into a real service, per @todo
* Convert Hooks into a non-static class, take lookup as an argument
* Update tests for new calling style
== Test plan ==
* CI/tests pass
* Use Special:ExpandTemplates with a preloaded domain and localhost,
observe preloaded link changes, localhost stays http
Bug: T271027
Change-Id: I0196350e85c09eedfba4dbf1dab81f9a757b2a12
For some reason Mozilla is blocking our requests from Toolforge,
using GitHub is something we know that works and should be the
same in practice.
Bug: T292242
Change-Id: Ic7d5da9758122ecb36f5e8f43716b4f8cf6f889d
This test downloads the specified revision of the HSTS preload list,
regenerates it, and compares it with the committed version at
domains.php.
In theory it would catch any potential code injection in domains.php,
which is hard to manually review due to its length.
Bug: T241522
Change-Id: Iee2a393c590b830c6e78adba48edc921e2873465
The test verifies:
* domains.php returns an array
* The array has at least 50,000 items (right now it has ~78,000)
* Each domain in the array passes a regex, and the value is either 1 or 0
Bug: T240743
Change-Id: Ic4e2c2e36ddcb0f775f4ac22d1418c814db5b389
