11.4.2. Соображения предложения Web-приложений через субдомены HSTS-компьютера
При этом сценарии, HSTS-компьютер анонсирует политику HSTS с директивой includeSubDomains, и существует также определенные web-приложения, предложенные в определенном субдомене HSTS-компьютера, такие, что агент пользователя, который часто взаимодействует с этими субдоменными web-приложениями, не обязательно взаимодействует с HSTS-компьютером. В таком случае, агенты пользователя не получат или не реализуют HSTS-политику.
Например, HSTS-компьютер является "example.com", и он сконфигурирован для формирования поля заголовка STS с директивой includeSubDomains. Однако, Web-приложение example.com вызывается из "www.example.com", а example.com просто переадресует агента пользователя на "http://www.example.com/".
Если поле заголовка STS сформировано "example.com", а агенты пользователя соединены с — "www.example.com" и "example.com" и не контактируют непосредственно со всеми агентами пользователя, в некотором ненулевом проценте случаев соединений, тогда некоторое число агентов пользователя не воспримут "example.com" в качестве HSTS-компьютера, а некоторое число пользователей "www.example.com" будут не защищены при политике HSTS.
Чтобы соответствовать таким требованиям, HSTS-компьютеры должны быть сконфигурированы таким образом, что поле заголовка STS формировалось непосредственно в домене HSTS-компьютера или субдомене, который представляет собой хорошо известную "точку входа" для одного из web-приложений, вне зависимости от того используется ли директива includeSubDomains или нет.
Таким образом, в нашем примере, если поле заголовка STS прислано как из "example.com", так и "www.example.com", условия будут выполнены. Если имеются любые другие известные входные точки в web-приложение, предлагаемые "example.com", таким как "foo.example.com", они также должны быть сконфигурированы для эмиссии поля заголовка STS.