☰

Apache против lighthttpd: разное поведение с типом mime

tag-icon • tag-icon debian osx apache-httpd lighttpd
Apache против lighthttpd: разное поведение с типом mime

Я написал приложение — веб-портал автоматического предоставления VPN-услуг на Python для устройств Apple.

Меня беспокоит разница в поведении тестового и производственного серверов: первый использует Apache, а второй — lighthttpd.

В lighhttpdфайле .mobileconfig, который открывается и «выполняется», например, он автоматически открывает SysPrefs, тогда как в Apache этого не происходит.

Я уже заметил, lighhtpdчто гораздо более расплывчато в отношении правильных Content-Typeопределений, однако проблема в том, что Safari будет .mobileconfigправильно загружать и «автоматически выполнять» файлы с , lighthttpdтогда как с Apache.

Что еще меня раздражает, так это то, что на обоих серверах я правильно определил соответствующие значения, mime.typeкак в:

lighthttpd.conf

$HTTP["url"] =~ "\.mobileconfig$" {
    setenv.add-response-header = ( "Content-Disposition" => "attachment" )
    mimetype.assign = (".mobileconfig" => "application/x-apple-aspen-config",
                    "" => "application/octet-stream")
}

Как в Apache это выглядит так:

dovpn.conf (виртуальный хост)

AddType application/x-apple-aspen-config .mobileconfig

Первый намек на разницу, по-видимому, на самом деле вытекает из этой add-response-headerдирективы в lighthttpd.

В сгенерированном HTML-коде у меня есть:

a download="profile.mobileconfig" href="../upload/8bd16b26-1473-4994-9803-8268a372cd0d.mobileconfig" type="application/octet-stream">Download automatic profile/a

и я делаю автоматическую загрузку этого через Javascript

//If in Safari - download via virtual link click
if (window.downloadFile.isSafari) {
    //Creating new link node.
    var link = document.createElement('a');
    link.href = sUrl;
    if (link.download !== undefined) {
        //Set HTML5 download attribute. This will prevent file from opening if supported.
        var fileName = sUrl.substring(sUrl.lastIndexOf('/') + 1, sUrl.length);
        link.download = fileName;
    }
    //Dispatching click event.
    if (document.createEvent) {
        var e = document.createEvent('MouseEvents');
        e.initEvent('click', true, true);
        link.dispatchEvent(e);
        return true;
    }
}

Содержимое страницы генерации также имеет только Content-Type:

Content-Type: text/html\n\n

как в Apache, так и в lighthttpd. Я проверил сеть, и не обнаружил никаких явных изменений в Content-Type, сделанных через lighthttpd.

Смогу ли я воспроизвести подобную функциональность setenv.add-response-headerс помощью Apache?

Я уже пробовал добавлять к хосту Apache:

<Files "*.mobileconfig">
      Header set Content-Disposition attachment
</Files>

и

SetEnvIf Request_URI "\.mobileconfig$" change_header
Header set Content-Disposition attachment env=change_header

и

SetEnvIf Request_URI "\.mobileconfig$" change_header
Header always add "Content-Disposition" "attachment" env=change_header

и

<Files "*.mobileconfig">
    Header append Content-Disposition attachment
</Files>

Я также попробовал создать в реальном каталоге .htaccessфайл с:

<IfModule mod_headers.c>
    <FilesMatch "\.mobileconfig$">
        ForceType application/octet-stream
        Header append Content-Disposition "attachment"
        Allow from all
    </FilesMatch>
</IfModule>

и

<IfModule mod_headers.c>
    <FilesMatch "\.mobileconfig$">
        ForceType application/octet-stream
        Header add Content-Disposition "attachment"
        Allow from all
    </FilesMatch>
</IfModule>

В обоих случаях, кроме attachment, я также использовал "attachment".

Обратите внимание, что mod_headers по умолчанию активен в Apache/Debian 9, и ни одна из этих альтернатив не сработала.

На самом деле, я только что вспомнил, lighthttpdчто используется HTTP и ApacheHTTPS. Я протестировал lighthttpd с HTTPS, и он также работает через HTTPS, в то время как Apache не работает.

Вывод curl -k -I https://localhost/cgi-bin/vpn.pyна сервере lighthttpd:

HTTP/1.1 200 OK
Content type: text/html
Content-Length: 331
Date: Thu, 01 Jun 2017 09:03:26 GMT
Server: lighttpd/1.4.45

Вывод curl -k -I https://localhost/cgi-bin/vpn.pyна сервере Apache:

HTTP/1.1 200 OK
Date: Thu, 01 Jun 2017 09:05:25 GMT
Server: Apache
Vary: Accept-Encoding
X-Frame-Options: sameorigin
Content-Type: text/html; charset=UTF-8

Более того, в Apache также:

$curl -k -I https://localhost/download/xxx.mobileconfig
HTTP/1.1 200 OK
Date: Thu, 01 Jun 2017 09:13:35 GMT
Server: Apache
Last-Modified: Thu, 01 Jun 2017 03:08:57 GMT
ETag: "1f3b-550dd5b89d8df"
Accept-Ranges: bytes
Content-Length: 7995
X-Frame-Options: sameorigin
Content-Disposition: attachment
Content-Type: application/x-apple-aspen-config

Используя Safari->Разработка->Показать веб-инспектор->Отладчик->щелчок на главной странице->Копировать как curl возвращает мне только "curl 'https://xxxx/cgi-bin/vpn.py' -Xnull" при вставке.

Я также пробовал отключать X-Frame-Options: "sameorigin", но это не помогло (я знал, что это маловероятно)

решение1

Похоже, использование .htaccessфайла решило проблему добавления в заголовки Content-Disposition.

Однако проблема копирования функциональности и дополнительная сложность отладки и тестирования, похоже, имеют другое объяснение.

Похоже, что и в последней бета-версии, и в текущей версии обновления Sierra .mobileconfigфайлы были исключены из списка «безопасных» для открытия файлов Safari по соображениям безопасности.

Вчера (или позавчера) я обновил MacOS на работе, сегодня обновил дома, и теперь .mobileconfigфайлы ни на рабочей, ни на тестовой системе больше не открываются автоматически.

Я только что обновил свой iPhone до iOS 10.3.3 beta, и это также, кажется, подтверждает тенденцию Apple рассматривать .mobileconfigфайлы обеспечения как потенциально опасные. Теперь, при нажатии на такой файл, вы увидите новое предупреждение:

Этот веб-сайт пытается открыть Настройки, чтобы показать вам профиль конфигурации. Вы хотите разрешить это?
Игнорировать - Разрешить

Связанный контент