Comments 17
golang.org/src/net/http/httputil/reverseproxy.go
Évelyne — девушка.
Мне иногда хочется прозрачный кэширующий прокси с поддержкой HTTP2 и с возможностью направлять трафик дальше через SOCKS-прокси. Пока не нашёлся с решением.
Если кратко, то ответ есть в первом абзаце поста. А именно, хотелось чтобы код в любой момент можно было доработать под конкретную задачу, потратив на какую-то мелочь соответствующее (маленькое) время и ни на кого не оглядываясь.
Подробнее:
Насчёт squid — у него основное предназначение другое. Активное вмешательство в трафик там если где-то и есть, то второстепенным функционалом.
А ещё он написан на C++, который я хоть и знаю, но не люблю, и исходники у него весят слишком много, чтобы держать их в голове постоянно, что в итоге плохо сказывается на возможности его быстрой доработки.
Про существование privoxy я до вашего комментария вообще не знал. Да, это что-то близкое по целям к моему прокси, но судя по его FAQ он для выполнения нужных задач (да и вообще в современном вебе, где везде https) работоспособен только в связке со squid. Получаются уже две независимые проги вместо одной, мне это не нравится (всмысле что их делают разные люди, не особо координируясь друг с другом, разные конфиги итд). И у него тоже слишком много исходников.
Вспомнил Proxomitron, свело олдскулы ;)
Ну, не то что бы требуется, но до состояния "скачать, распаковать и в пару команд запустить" я его всё-таки довёл ради публикации — иначе это было бы неуважением к потенциальным пользователям.
А указанные сервисы не люблю (не люблю ни сам git, ни идею централизованных хостингов, ни Microsoft который владеет GitHub'ом).
Выложил небольшое обновление (ссылки обновлены). Кроме чисто технических правок, что изменилось:
1) исправлен баг при парсинге некорректного http-заголовка без двоеточия (при поиске двоеточия не учитывался завершающий нулевой байт строки заголовка, и двоеточие могло "найтись" в мусоре после конца строки, который был бы посчитан частью заголовка) как в запросе от браузера, так и в ответе от сайта, мог привести к segfault или (при очень "удачном" стечении обстоятельств) к утечке в браузер (а из него через js — на злонамеренный сервер) случайных областей памяти процесса прокси, содержащих данные прошлых проксированных запросов; или злонамеренный клиент мог попытаться отправить на "нужный" сервер обрывки длинных заголовков предыдущего запроса, прошедшего через тот же прокси-процесс;
2) ютуб перестал слушаться опцию &disable_polymer=true, теперь для той же цели используется фейковый юзер-агент;
3) оказывается в сертификатах бывают доменные имена не в нижнем регистре (пример: Techlibrary.hpe.com), теперь домен сравнивается без учёта регистра;
Локальный прокси-сервер для фильтрации браузерного трафика