Используйте FallbackResource, даже если каталог существует

Я тоже на это отвечаю, потому что уверен, что проблема связана с тем, как mod_dir.c работает внутри и я думаю это Жук.

Если ресурс не может быть сопоставлен с локальной файловой системой, функция fixup_dflt() будет работать, используя FallbackResource чтобы определить, какой документ следует загрузить вместо этого.

Однако когда ресурс жестяная банка быть сопоставленным с локальной файловой системой и каталогом, он попытается разрешить документ, запустив fixup_dir(); эта функция выполняет итерацию по списку DirectoryIndex значений, пока не будет найден первый подходящий документ.

В моем случае в конфигурации есть пустой список DirectoryIndex ценности, поэтому fixup_dir() завершится ошибкой, и будет возвращено 404.

У меня работает следующий патч (PR):

static int dir_fixups(request_rec *r)
{
    if (r->finfo.filetype == APR_DIR) {
-        return fixup_dir(r);
+        if (fixup_dir(r) != OK) {
+           /* use fallback */
+           return fixup_dflt(r);
+        }
+
+        return OK;
    }
    else if ((r->finfo.filetype == APR_NOFILE) && (r->handler == NULL)) {
        /* No handler and nothing in the filesystem - use fallback */
        return fixup_dflt(r);
    }
    return DECLINED;
}

Это в основном пытается fixup_dflt() после fixup_dir() не смогли.

Обновление 2015-04-21

А исправить внесен в проект, запланированный на 2.5; он также может быть перенесен на 2.4.

Обновление 2015-05-18

Исправление было вернулся так как:

[...] это [по крайней мере] вызывает FallBackResource забить раньше mod_autoindex мог бы сработать.

Я все еще пытаюсь понять, как избежать такой ситуации.

Ваша конфигурация должна быть правильной.

Проблема, как ни странно, кажется mod_deflate.

После успешного воспроизведения вашей конфигурации здесь (не получение 404), я также получил 5-секундную задержку. Однако я заметил, что когда UA пропускает gzip из заголовков Accept-Headers страница отображается / принимается мгновенно. Вы можете проверить это сами с помощью wget.

Интересно, что дальнейшая отладка с strace показывает, что apache отправляет содержимое вашего FallbackResource в розетку вашего клиента без заметной разницы в задержке для обе случаи. Это также очевидно на проводе, где пакет ответа отправляется с сервера клиенту после HTTP-запроса без какой-либо заметной задержки.¹.

Похоже, что при использовании mod_deflate в этом случае, однако, UA не знает, когда данные, отправленные сервером, заканчиваются, и, таким образом, ничего не отображает до истечения времени ожидания TCP-соединения.² и принудительно закрывается сервером. Это соответствует HTTP / 1.0, где закрытое соединение означает конец содержимого.

Для HTTP / 1.1, на сервере есть другие средства, доступные для сигнализации о конце содержимого - но ничего из этого, похоже, здесь не происходит.

Однако, если ошибка скрывается в mod_dir или mod_deflate, сейчас мое время выходит за рамки моего свободного времени. Я заставил его работать безупречно, отключив сжатие gzip; в качестве временного решения, пока проблема не будет окончательно решена, вы можете выборочно отключить gzip.

¹) Это говорит нам о том, что проблема не в не очищенных буферах на сервере.
²) По умолчанию тайм-аут составляет 5 секунд с apache - отсюда ваши 5 секунд.