@zkrvndm
Боты, парсеры, расширения

Как сделать запрос через http-прокси?

Используя browser.webRequest.onBeforeSendHeaders я могу редактировать заголовки запросов. Можно ли при помощи него каким-нибудь образом вручную сконфигурировать полностью валидный запрос к http-прокси? Если вдруг да, то какая у запроса должна быть структура в плане отсылаемых заголовков и самого тела запроса?

Спойлер для капитанов Очевидность
Обратите внимание, я в курсе про существования метода browser.proxy.settings.set - данный метод действительно позволяет установить в браузере один конкретный прокси и делать через него запросы. Однако, это совершенно не подходит, если Вам нужно сделать несколько одновременных запросов через разные прокси!

Как ВРУЧНУЮ сделать запрос через http-прокси используя фоновый процесс браузерного расширения?

Какой должна быть структура запроса?

Моя попытка переделать заголовки. Содержимое backgrouns.js:
function handler(e) {
	e.requestHeaders.push({ name: "Proxy-Authorization", value: "Basic " + btoa("логин_от_прокси:пароль_от_прокси") });
	for (var header of e.requestHeaders) {
		if (header.name.toLowerCase() === "host") {
			header.value = 'целевой хост';
		}
	}
	return {requestHeaders: e.requestHeaders};
}

browser.webRequest.onBeforeSendHeaders.addListener(handler, { urls: [ "http://адрес_прокси_вместе_с_портом" ] }, [ "blocking", "requestHeaders" ] );


Далее стучусь на прокси и смотрю ответ:
await (await fetch('http://193.233.80.174:65233')).text();

Авторизацию прохожу успешно, но сам запрос один фиг не валидный.
  • Вопрос задан
  • 135 просмотров
Решения вопроса 1
У HTTP прокси несколько другой формат запроса, в обычном HTTP запросе

GET /somepath HTTP/1.1
Host: example.com

в случае прокси запрос должен быть

GET http://example.com/somepath HTTP/1.1
Host: example.com


поэтому либо прокси должен поддерживать запросы в стиле веб-сервера (т.н. транспарентный прокси) либо надо иметь возможно менять не только заголовки, но и сам запрос. В некоторых прокси транспарентные запросы принимаются "из коробки", в других (например squid) их надо разрешать соответствующе директивой, где-то они могут совсем не поддерживаться. Будет ли работать транспарентный режим в сочетании с Proxy-Authorization - так же зависит от прокси.

В случае HTTPS манипуляция заголовками не даст возможности работать с прокси, надо иметь возможность делать отдельный запрос (CONNECT) перед установкой TLS-соединения

Вы можете решить вашу проблему установив локальный транспарентный прокси без аутентификации, который будет перенаправлять трафик в родительский прокси с аутентификацией, например для 3proxy:
auth iponly
allow *
parent 1000 http адрес порт логин пароль
proxy -i127.0.0.1 -p3128
Ответ написан
Пригласить эксперта
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы