Разрешено ли промежуточному прокси-серверу добавлять файлы cookie во время аутентификации прокси?
Недавно я столкнулся с определенным устройством безопасности (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 долгое время оставалась посредственным по качеству ...