Назад | Перейти на главную страницу

Документ по умолчанию по HTTPS не работает с iPhone 6 и iPad?

Конфигурация сервера:

У меня есть веб-приложение, которое использует встроенный модуль документов по умолчанию во всем приложении, чтобы скрыть имена файлов. Когда я пытаюсь получить доступ к любому из URL-адресов веб-сайта через HTTPS, которые относятся к папкам (например, 1) https://example.com/, 2) https://example.com/folder/и т. д.), которые сопоставляются с документом по умолчанию (index.cfm, index.htm) из Safari или Chrome на iPhone 6 или более ранней версии iPad (устройства, с которыми я легко могу протестировать) соединение, кажется, зависает на некоторое время, а затем в конечном итоге происходит сбой с общим сообщением браузера (у меня его нет передо мной, но я не думаю, что это необходимо, пожалуйста, прочтите).

Я могу получить доступ ко всем URL-адресам с любого ПК, настольного компьютера или ноутбука из Chrome, Firebug, IE и Edge, а также с нового ноутбука Mac моего коллеги. Я пробовал тестировать общие htm- и ​​cfm-файлы "hello world", чтобы исключить интерпретацию кода браузером: html / jquery / и т. Д.

Чтобы исключить проблему с iPhone 6, я создал точно такой же набор тестовых файлов с другого сервера в совершенно другом домене и успешно запустил сервер документов по умолчанию.

Я могу получить доступ к URL-адресам через HTTPS с iPhone 6 или iPad, если они включают имя файла (например, полностью до: /index.htm, или: /folder/index.cfm).

Я могу получить доступ ко всем URL-адресам через HTTP (небезопасно) с iPhone 6 или iPad, если запрос выполняется по небезопасному каналу (например, URL-адреса 1 и 2 выше, но с HTTP вместо HTTPS).

На стороне сервера я устанавливаю широкое правило отслеживания неудачных запросов (все HTTP-ответы 100-999). Когда я смотрю каталог во время неудачной попытки запроса, я вижу, что файлы XML создаются в течение нескольких секунд из одного запроса (подразумевая, что браузер iPhone неоднократно пытается подключиться?). Последовательность в журналах трассировки XML, кажется, указывает на то, что все в порядке (кажется, что правильные сопоставления обработчиков срабатывают / срабатывают, ответ HTTP 200 OK) некоторое время до следующего:

Информационная 166. -GENERAL_FLUSH_RESPONSE_END

Была предпринята попытка выполнить операцию при несуществующем сетевом подключении.

Это не имело значения, когда я пробовал каждую комбинацию следующего в IIS 10:

Где моя проблема? Это не похоже ни на настройки IIS 10, ни на iPhone. Сертификат SSL, кажется, работает, когда вышеуказанные тестовые примеры успешно выполняются.