Java: системные свойства и запрет схем внутри туннеля

Ловлю неприятную вещь и хочу свести опыт в одно место, потому что вопрос всплывает у каждого второго, кто запускает джаву через посредника.

Обычный http идёт нормально:

java -Dhttp.proxyHost=193.0.2.44 -Dhttp.proxyPort=8000 -jar sbor.jar

Стоит переключиться на https, и прилетает отказ с кодом 407, хотя пара входа задана и та же самая пара прекрасно работает в curl с той же машины. Причём отказ приходит мгновенно, до всякого сетевого обмена, будто клиент даже не пробовал.

Кто сталкивался, скажите сразу: это про disabledSchemes или я копаю не туда?

Про него. В джаве базовый вход внутри туннеля выключен по умолчанию, само свойство так и называется:

-Djdk.http.auth.tunneling.disabledSchemes=""

Пустое значение снимает запрет, и вход через CONNECT начинает проходить. Есть парное свойство для обычных запросов без туннеля, jdk.http.auth.proxying.disabledSchemes, там по умолчанию запрета нет.

Мгновенный отказ до обмена это как раз оно: клиент видит, что предложенная схема ему запрещена, и обрывает разговор сам.

Именно так и выглядело. Проверил, пошло. Заодно собрал полный набор свойств, чтобы не искать по кускам:

java \
  -Dhttp.proxyHost=193.0.2.44 -Dhttp.proxyPort=8000 \
  -Dhttps.proxyHost=193.0.2.44 -Dhttps.proxyPort=8000 \
  -Dhttp.nonProxyHosts="localhost|127.0.0.1|*.local" \
  -Djdk.http.auth.tunneling.disabledSchemes="" \
  -jar sbor.jar

Три момента, на которых спотыкаются почти все.

Свойства для http и https разные, одно другое не покрывает. Задали только первое, и весь https пойдёт напрямую, молча, без единого сообщения об ошибке. Разделитель в списке исключений вертикальная черта, запятая там не понимается, звёздочка работает только слева. И https.proxyHost описывает адрес самого посредника, схема тут про целевой запрос.

а логин с паролем куда вписывать? в свойствах их вроде нет

Через Authenticator, отдельным куском кода:

import java.net.Authenticator;
import java.net.PasswordAuthentication;

Authenticator.setDefault(new Authenticator() { @Override protected PasswordAuthentication getPasswordAuthentication() { if (getRequestorType() == RequestorType.PROXY) { return new PasswordAuthentication( System.getProperty("proxy.user"), System.getProperty("proxy.pass").toCharArray()); } return null; } }); ```

Проверка на RequestorType.PROXY обязательна. Без неё пара уедет и на целевой сайт, если тот попросит вход, а этого никто не ждёт.

Добавлю со стороны провода, раз тема техническая.

Когда сомневаетесь, куда именно джава ходит, включайте её собственный журнал обмена, он показывает и заголовки, и порядок команд:

-Djavax.net.debug=ssl:handshake -Djava.util.logging.config.file=logging.properties
-Dsun.net.www.protocol.http.HttpURLConnection.level=FINEST

Если в дампе после отказа нет второй попытки с заголовком входа, ищите запрет схем. Если попытка есть и всё равно отказ, ищите ошибку в паре или непривязанный адрес.

По моему опыту разбор быстрее всего идёт в таком порядке. Сначала смотрим, дошёл ли до посредника хоть один пакет: нет обмена на нужном порту вообще, значит свойства не подхватились и джава ушла напрямую мимо всего, что вы прописали. Дальше смотрим первую строку туннеля: там должно стоять имя целевого узла с портом. Видите вместо него обычный запрос с путём, значит https поехал как http, и вы задали только половину свойств.

Отдельно предупрежу про сокеты: если в дампе на порту тишина, а программа при этом что-то делает, проверьте, не перебивает ли настройку сама библиотека. Многие клиенты внутри держат собственные поля и системные свойства читают только при старте, до первого обращения. Правка свойств из кода после того, как соединение уже создано, ни на что не влияет, их надо задавать флагами при запуске.

Свёл всё в шпаргалку, повешу тут для будущих поисков:

У меня после снятия запрета схем и добавления https-пары всё поехало ровно. Спасибо всем, тему считаю разобранной.