Azure CDN - включение HTTP-сжатия - размещенная веб-роль

Кто-нибудь успешно настроил Azure CDN для сжатия HTTP, используя свою размещенную веб-роль? У нас возникают проблемы с сжатием содержимого HTTP на пограничных серверах Azure. CDN только кэширует несжатую версию содержимого.

Если мы нажмем ссылку на ресурс (webresource.axd) из незазорного подхода, он сжимает через gzip (используя xxxx.cloudapp.net/cdn/webresource.axd), как и ожидалось. Однако, как только мы укажем нашу ссылку ресурса на Azure CDN (xxxx.vo.msecnd.net), содержимое будет загружено без сжатия, несмотря на то, что браузер сообщает Azure CDN, что он принимает gzip.

I отправил эту же проблему в Azure Forums, но пока никто не ответил.

При устранении неполадок, похоже, что Azure CDN удаляет HTTP-заголовок Accept-Encoding. Просто интересно, если у других была такая же проблема.

Основные принципы Azure CDN...

Как работает CDN Windows Azure со сжатым контентом?

Windows Azure CDN не будет изменять (или добавлять) сжатие ваших объектов. Windows Azure CDN уважает любое сжатие, обеспечиваемое источником, основанным на заголовке "Accept-Encoding". Начиная с версии 1.4, Azure Storage не поддерживает сжатие. Если вы используете доставку объектов хостинга, вы можете настроить IIS для возврата сжатых объектов.

Что мы видим, так это то, что CDN не уважает исходное Accept-Encoding, которое удаляется.

Ответ 1

Было обнаружено через пробную версию и ошибку, что Azure CDN имеет текущее ограничение, которое не будет передавать заголовок HTTP Accept-Encoding, если не найдет параметр QueryString, содержащий тип сжимаемого имени файла (.js,.cs) или вы запрашиваете файл по его первоначальному имени (jquery.js, site.css и т.д.).

Это означает, что если вы используете обработчик ресурсов AXD (WebResource.axd и т.д.), сжатие HTTP не будет выполнено. Azure CDN передаст только Accept-Encoding, если вы добавите параметр QueryString с расширением .cs или .js.

Мы используем пользовательский обработчик ресурсов AXD, поэтому это было легко реализовать. Мы просто применили &group=core.js и &group=core.css для наших объединенных минимизированных ресурсов, и сжатие работало, как ожидалось. Это, к сожалению, не существует в текущей документации Azure CDN.

Короче говоря, нам пришлось преобразовать наши URI из этого:

https://xxxx.vo.msecnd.net/resourceManager.axd?token=HL80vX5hf3lIAAA

:

https://xxxx.vo.msecnd.net/resourceManager.axd?token=HL80vX5hf3lIAAA&group=core.js

Как только Azure CDN увидит .js в querystring, он вернет сжатую версию ресурса.

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

Ответ 2

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

Windows Azure CDN поддерживает сжатый контент по HTTP1.0, и большую часть времени проблема, которую я видел, связана с проблемой HTTP 1.0 vs HTTP 1.1. Поэтому, когда вы запрашиваете CDN-объект непосредственно из своей веб-роли через HTTP 1.0 (используя команду wget), вы должны получить сжатый контент, если все правильно. Если вы получаете не сжатый контент, тогда вы знаете, где проблема. Убедитесь, что вы настроили приложение и IIS для доставки сжатого содержимого клиентам HTTP 1.0, а также клиентам HTTP 1.1.

Я написал подробную запись в блоге, чтобы точно добавить HTTP-сжатие с Azure CDN через веб-роль:

http://blogs.msdn.com/b/avkashchauhan/archive/2012/03/05/enableing-gzip-compression-with-windows-azure-cdn-through-web-role.aspx

Ответ 3

Эти ответы о добавлении расширений .css/.js больше не применяются к недавнему обновленному серверу службы Azure (Q1 2014).

Я провел изолированный тест с новым проектом веб-роли Cloud Service сегодня и новым экземпляром CDN.

Я поместил файл /cdn/style -1.css в свою веб-роль (один экземпляр) и получил доступ к нему через CDN. Он не был сжат. Доступ непосредственно к WAS сжат.

Исправление для моей роли веб-роли, содержащей gzip'd, состояло в том, чтобы обеспечить настройку конфигурации IIS noCompressionForProxies "false" (по умолчанию это правда).

Это привело к тому, что Azure CDN отправил мне содержимое gzip'd.

Добавление расширений css/js не имело значения.

Обратите внимание, что при тестировании этого изменения это изменение конфигурации хоста, поэтому вы должны перезапустить IIS через диспетчер IIS (не iisreset), чтобы он вступил в силу. Наконец, чтобы протестировать изменение, обязательно создайте новый файл (например, style-2.css) и попросите его через CDN, чтобы он снова извлек его из исходного сервера.