HTTPS с сертификатом

Потому что имя файла на другом конце ссылки не является (или может не являться) именем файла в каталоге, к которому вы обращаетесь с помощью ls.

Две проблемы с отображением имени цели символической ссылки вместо имени самой ссылки:

  1. Файл не существует. Если имя цели символической ссылки отображается в списке каталогов, можно подумать, что это имя файла в этом каталоге, но это не так. Имя цели не является именем, по которому вы обращаетесь к файлу в этом каталоге; файл с таким именем не существует (в этом каталоге), или, в худшем случае, это может быть совершенно другой файл (или каталог, или что-либо еще), когда к нему обращаются по этому имени.

  2. Может показаться, что файлы имеют одинаковые имена. Если отобразить имя цели символической ссылки, то можно обнаружить, что оно полностью совпадает с именем другого файла в этом каталоге, что не может быть правдой в системе Unix.

В таких случаях это приводит к путанице для пользователей, и им придется проверять листинг с помощью ls без -L, что сделает опцию -L довольно бессмысленной.

Это (не отображение имени цели) также является поведением, указанным в POSIX, вполне явно:

Оценивайте информацию о файле и тип файла для всех символических ссылок (названных в командной строке или встречающихся в иерархии файлов) как информацию о файле, на который ссылается ссылка, а не саму ссылку; однако, ls должен записывать имя самой ссылки, а не файла, на который ссылается ссылка. Когда -L используется с -l, записывайте содержимое символических ссылок в длинном формате (см. раздел STDOUT).

В разделе "Обоснование" руководства POSIX ls об этом больше ничего не говорится.

1
27.05.2016, 18:08
1 ответ

Да, начните с фильтрации вашего access.log с http и POST вот так:

Доступы с HTTP:

grep http /var/log/apache2/access.log | grep -v https | grep POST

Доступы с HTTPS:

grep https /var/log/apache2/access.log | grep POST
2
27.01.2020, 23:35

Теги

Похожие вопросы