Недавно я столкнулся с определенным устройством безопасности (BlueCoat), которое требует, чтобы все подключения к Интернету должны быть проксированы через него (привет, человек посередине) и, соответственно, использует специальный сертификат SSL для перехвата всего трафика.
Это мешало нормальной работе Git, даже если соответствующий http.proxy и http.sslCAInfo были установлены свойства, чтобы убедиться, что само соединение SSL работает.
Использование переменной окружения GIT_CURL_VERBOSE=1, мы обнаружили, что при использовании git clone, происходит HTTP 407 (требуется проверка подлинности прокси). Git правильно выполняет эту аутентификацию, и в конце этого устройство возвращает HTTP 200 с заголовком cookie. Set-Cookie.
Затем Git подключится к целевому серверу, но без файл cookie, ведущий к HTTP 401.
Решением для этого является установка параметра конфигурации git http.saveCookies=true
Вопрос: Разрешено ли стандартами RFC, что промежуточный прокси-сервер добавляет файлы cookie?
Энтони Рич задал тот же вопрос списку рассылки http-state но без ответа. Он заметил, что в
RFC 2965 HTTP State Management Mechanism, 3.5 Caching Proxy Role он говорит: Прокси-серверы НЕ ДОЛЖНЫ вводить собственные заголовки Set-Cookie2 (Cookie) в ответах (запросах) прокси.
Однако заменяет RFC 6265 больше не упоминает об этом.
Файлы cookie HTTP - это беспорядок. Нет настоящего стандарта; RFC, как бы то ни было, просто пытается задокументировать, что делают реальные пользовательские агенты.
В любом случае RFC, который вы, вероятно, захотите прочитать, RFC 7235, который указывает, что прокси-серверы должны отправлять заголовок Proxy-Authenticate со статусом 407 для запроса информации аутентификации, а пользовательские агенты, получающие это, должны повторять запрос с заголовком Proxy-Authorization, содержащим информацию аутентификации для прокси.
Для предоставления этой информации можно использовать ряд методов запроса / ответа; наиболее широко используется "базовый" (RFC 7617), поскольку почти все, что говорит HTTP, реализует его.
IANA поддерживает реестр известных схем аутентификации HTTP. Как правило, они используют заголовки HTTP, названные ранее, или они отмечены как несовместимые. Ни один из них не использует файлы cookie для аутентификации.
Я не могу сказать, разрешено ли прокси-серверу добавлять или изменять файлы cookie. RFC действительно не кажутся очень ясными по этому поводу. Это конечно неожиданный поведение, особенно для аутентификации. А BlueCoat уже долгое время является посредственным по качеству ...