Azure CDN — имя узла запроса отличается от исходного имени узла

Допустим, у нас есть имя личного домена в конечной точке Azure CDN (например, личный домен — www-mydomain-com), в котором используется управляемый сертификат Azure CDN.

Источником конечной точки CDN является WordPress, работающий в службе приложений Azure — тип источника = веб-приложение.

Собственное имя узла службы приложений Azure — mydomain-azurewebsites-net . Следует отметить, что в настоящее время в службу приложений Azure также добавлен тот же личный домен (www-mydomain-com) с добавленным действительным общедоступным доверенным сертификатом.

DNS CNAME для www-mydomain-com разрешается в имя узла конечной точки Azure CDN (mydomain-azureedge-net).

Источник конечной точки CDN задается с пустым заголовком узла Origin в соответствии с подсказкой, предоставленной порталом Azure: «Значение заголовка узла, отправляемое в источник с каждым запросом. Если оставить это поле пустым, имя узла запроса определяет это значение. Источники Azure CDN, такие как веб-приложения, хранилище BLOB-объектов и облачные службы, требуют, чтобы это значение заголовка узла соответствовало исходное имя хоста по умолчанию."

Все это хорошо работает. Из журнала мы можем подтвердить, что клиент запрашивает www-mydomain-com, а запросы к источнику также относятся к www-mydomain-com.

Если мы изменим заголовок хоста Origin на mydomain-azurewebsitesnet, то я увижу странное поведение.

Клиент запрашивает www-mydomain-com — и страница загружается как обычно — я могу подтвердить, что это ошибка кеша.

Клиент запрашивает другой URL-адрес — www-mydomain-com/test — это снова промах кеша, однако журналы показывают вызов к источнику — имя хоста, как и ожидалось, установлено на mydomain-azurewebsites-net .

Странно то, что клиент затем направляется на mydomain-azurewebsites-net/test, а НЕ на www-mydomain-com/test.

Если клиент повторно запрашивает www-mydomain-com/test - страница нормально загружается из кеша.

Похоже, что исходный запрос клиента передается источнику с использованием заголовка узла источника - при промахе кеша. Чего я ожидал, так это того, что запросы всегда обслуживаются клиентам из Azure CDN и что CDN при необходимости извлекает содержимое из источника в кеш (используя заданные заголовки узла источника).

Чего я хотел бы добиться, так это не добавлять общедоступный доверенный сертификат в службу приложений (просто полагайтесь на сертификат azurewebsite-net для подключения CDN к источнику TLS).

Я что-то упустил или это просто ограничение Azure CDN (я не использую Verizon или Akamai Azure CDN).

Почему для начала вы добавили собственное имя хоста в свой сервис приложений? Вы пробовали удалить это? Тогда служба приложений не должна ничего путать и должна быть доступна только через foo.azurewebsites.net.

silent 17.03.2022 10:07
Как установить LAMP Stack - Security 5/5 на виртуальную машину Azure Linux VM
Как установить LAMP Stack - Security 5/5 на виртуальную машину Azure Linux VM
В предыдущей статье мы завершили установку базы данных, для тех, кто не знает.
Как установить LAMP Stack 1/2 на Azure Linux VM
Как установить LAMP Stack 1/2 на Azure Linux VM
В дополнение к нашему предыдущему сообщению о намерении Azure прекратить поддержку Azure Database для MySQL в качестве единого сервера после 16...
0
1
31
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

Я зарегистрировал билет MS, и в ходе устранения неполадок у меня был момент лампочки. Вызов источника с заголовком хоста mydomain-azurewebsitesnet приводит к тому, что серверная часть WordPress загружает страницу с относительными ссылками в кэш с хостом mydomain-azurewebsitesnet. Это означает, что все ссылки на странице, даже если они обслуживаются из кеша, ссылаются на хост-источник. Одним из решений является жесткое связывание кода с хостом www-mydomain-com — это не идеально.

Не уверен, почему я об этом подумал, но дальнейшее тестирование показало, что Azure CDN вызывает источник с использованием HTTPS - требуется, чтобы сертификат источника имел заголовок узла в сертификате, НО - сертификат НЕ должен быть в пределах его действительных дат. т.е. вы можете использовать просроченный сертификат с правильным именем хоста.

Это позволяет мне достичь моей первоначальной цели.

Azure CDN — оставьте заголовок хоста источника пустым — это означает, что заголовок хоста клиента проходит через исходные запросы — это означает, что все мои ссылки работают правильно. Исходное веб-приложение использует сертификат с истекшим сроком действия, в котором указан правильный хост (который соответствует хосту, отправленному клиентом). Запросы от CDN к источнику по HTTPS все еще работают.

Это позволяет мне использовать предоставленный Azure CDN и управляемый сертификат TLS (выданный DigiCert), и мне НЕ нужно беспокоиться об обновлении и управлении сертификатом в веб-приложении службы приложений Azure (сертификат с истекшим сроком действия все еще работает).

Другие вопросы по теме