Коллеги, добрый день.
Имеется опубликованная база 1С на веб сервере Apache. К Apache привязан PHP. Когда ввожу адрес localhost:8045/base1, почему-то пролетает мимо php. Однако если я введу localhost:8045, он войдет в систему.

Искал в интернете описания не нашел. Подскажите пожалуйста, как это исправить?

httpd.conf:

Listen 8045
PHPIniDir "C:/SERVER/BIN/PHP"
AddHandler application/x-httpd-php .php
LoadModule php_module "C:/SERVER/BIN/PHP/php8apache2_4.dll"
DocumentRoot "c:/SERVER/DATA"
<Directory "c:/SERVER/DATA">

# 1c publication
Alias "/base1" "C:/Server/DATA/1C/"
<Directory "C:/Server/DATA/1C/">
	AllowOverride All
	Options None
	Require all granted
	SetHandler 1c-application
	ManagedApplicationDescriptor "C:/Server/DATA/1C/default.vrd"
</Directory>

SetHandler 1c-application - тебе ни о чем не говорит?

(1) Говорит, что выполняется обработчиком 1с-application.
Как тогда будет корректно?

Корректно что?
Я так и не увидел, что в результате должно произойти?
Внутри алиаса 1С ты не сможешь php.

(3) Суть задачи следующая.
Есть один сервис, который синхронизируется по http сервису к базе 1С. Аутентификация происходит по Basic.
Проблема в следующем. Этот сервис обязывает при некорректно отправленной аутентификации наш сервис (http) должен вернуть код ответа не 401, а 200 с необходимом json текстом.
Планировал это всё реализовать через php реализовать. Все в целом работает, php обрабатывает как положено, но работает только если обращаться непосредственно к самому ServerName (localhost:8045)....

(0) Когда ввожу адрес localhost:8045/base1, почему-то пролетает мимо php.   -  У тебя по этому адресу прописан обработчик 1с. Апач его и вызывает

(4) Через nginx прокси только тогда.
Ну или всегда пускать в сервис и авторизацию уже внутри 1c проверять

(6) не нашел в инете как это сделать...Если есть ссылка отправьте пожалуйста.

(7) Какой вариант?

+(8) Можно попробовать следующий вариант. Возможно сработает

# 1c publication
Alias "/base1" "C:/Server/DATA/1C/"
<Directory "C:/Server/DATA/1C/">
	AllowOverride All
	Options None
	Require all granted
	SetHandler 1c-application
	ManagedApplicationDescriptor "C:/Server/DATA/1C/default.vrd"
	ErrorDocument 401 "C:/Server/DATA/1C/error401.php"
</Directory>

в error401.php указать

<?php header("Status: 200 OK"); ?>

Только вот нужен относительный путь наверно, а не абсолютный.

ErrorDocument 401 "/error401.php"

(9) к сожалению не сработало и (10) тоже не сработало....
Весь интернет обшарил...
Есть ещё идеи?

(11) что не сработало то? У себя потестил - срабатывает.
У меня php нет, но страница возвращается из error401.html
И я вынес "ErrorDocument 401 "/error401.php"" за пределы алиаса - на весь конфиг.
И непонятно какая авторизация у тебя 401 выдает. Авторизация в апаче или в 1С?
Ну самое правильное ставить реверс прокси nginx
Например https://its.1c.ru/db/metod8dev/content/5980/hdoc
и подменять в нем ошибки.
Типа: "если апач вернул 401, тогда возвращаем клиенту 200 + json"
Вот пример перехвата ошибок nginx
https://itnots.ru/nginx/perehvat-oshibok-404-i-50x-vo-vremya-proksirovaniya/

Вот из мануалов еще
http://nginx.org/ru/docs/http/ngx_http_core_module.html#error_page

Синтаксис:	error_page код ... [=[ответ]] uri;
Умолчание:	—
Контекст:	http, server, location, if в location
Задаёт URI, который будет показываться для указанных ошибок. В значении uri можно использовать переменные.

Пример:

error_page 404             /404.html;
error_page 500 502 503 504 /50x.html;
При этом делается внутреннее перенаправление на указанный uri, а метод запроса клиента меняется на “GET” (для всех методов, отличных от “GET” и “HEAD”).

Кроме того, можно поменять код ответа на другой, используя синтаксис вида “=ответ”, например:

error_page 404 =200 /empty.gif;
Если ошибочный ответ обрабатывается проксированным сервером или FastCGI/uwsgi/SCGI/gRPC-сервером, и этот сервер может вернуть разные коды ответов, например, 200, 302, 401 или 404, то можно выдавать возвращаемый им код:

error_page 404 = /404.php;
Если при внутреннем перенаправлении не нужно менять URI и метод, то можно передать обработку ошибки в именованный location:

location / {
    error_page 404 = @fallback;
}

location @fallback {
    proxy_pass http://backend;
}
Если при обработке uri происходит ошибка, клиенту возвращается ответ с кодом последней случившейся ошибки.
Также существует возможность использовать перенаправления URL для обработки ошибок:

error_page 403      http://example.com/forbidden.html;
error_page 404 =301 http://example.com/notfound.html;
В этом случае по умолчанию клиенту возвращается код ответа 302. Его можно изменить только на один из кодов ответа, относящихся к перенаправлениям (301, 302, 303, 307 и 308).

До версий 1.1.16 и 1.0.13 код 307 не обрабатывался как перенаправление.
До версии 1.13.0 код 308 не обрабатывался как перенаправление.
Директивы наследуются с предыдущего уровня конфигурации при условии, что на данном уровне не описаны свои директивы error_page.

Проверил, и да. То что в алиасе 1С не возвращает страницы ошибок описанных в ErrorDocument.

(0) я конечно не архитектор данного решения... ну сделай проброс с пхп скрипта, на http 1c