Mstari wa ombi unaopitisha HTTP ya Node kupitia proksi

Jenga ombi la kawaida la HTTP la proksi kwa mteja msingi wa Node kwa kutenganisha mwisho wa muunganisho, lengo kamili na kichwa cha Host.

Katika ombi la kawaida la HTTP kupitia proksi ya mbele, Node huunganisha na proksi na kutuma URL ya lengo katika mstari wa ombi. Thamani tatu zinaelezea ombi hilo moja:

ThamaniMfano
Mwisho wa muunganisho wa TCPproxy.example:8080
Lengo la ombihttp://example.com/news?q=proxy
Kichwa cha Hostexample.com

Mfano huu wa Node 22 unaweka utengano wazi:

const http = require('node:http');
const destination = new URL('http://example.com/news?q=proxy');

const request = http.get({
  hostname: 'proxy.example',
  port: 8080,
  path: destination.href,
  headers: { Host: destination.host },
  signal: AbortSignal.timeout(15000),
}, (response) => {
  console.log(response.statusCode);
  response.on('error', console.error);
  response.resume();
});
request.on('error', console.error);

Mwisho ni kishika nafasi; chagua mtahiniwa kutoka orodha ya proksi za HTTP kwa jaribio la HTTP la umma na uangalie jibu lake. Mfano huondoa jibu baada ya kuchapisha hali; programu inaweza kutumia mwili badala yake. Swali linabaki kuwa sehemu ya lengo la ombi.

Kwa nini URL kamili inastahili kuwa hapo

Seva asilia kwa kawaida hupokea lengo kama /news?q=proxy. Proksi ya mbele pia inahitaji lengo, kwa hivyo HTTP/1.1 inafafanua lengo katika umbo kamili:

GET http://example.com/news?q=proxy HTTP/1.1
Host: example.com

Chini ya kanuni za HTTP/1.1, proksi inayopokea umbo kamili hutumia mamlaka ya URI inapopeleka na kubadilisha uwanja wa Host uliopokelewa usiolingana. Kutuma kichwa cha Host cha lengo kinacholingana bado kunaifanya ombi linalotoka lisiwe na utata. Jina la mwenyeji wa muunganisho wa Node ni mpatanishi, kwa hivyo weka kichwa kwa makusudi badala ya kutegemea anwani hiyo ya muunganisho.

Ikiwa uthibitishaji unahitajika, vitambulisho vya proksi ni vya hatua yake yenyewe. Chaguo la ombi auth la Node huunda kichwa cha Authorization kwa rasilimali; si chaguo la jumla la kuingia kwenye proksi. Tumia mpango unaohitajika na proksi na mteja wa proksi anayefaa wakati ubadilishanaji ni mgumu zaidi.

HTTPS huongeza handaki

Mfano huu unashughulikia upelekaji wa HTTP wa kawaida. Muunganisho wa HTTPS kupitia proksi ya HTTP wa kawaida huomba CONNECT example.com:443 kwanza, kisha huanzisha TLS kuelekea lengo ndani ya handaki lililokubaliwa. Kubadilisha URL ya mfano kuwa HTTPS hakuongezi hatua hizo.

Kwa HTTPS au mzigo mchanganyiko, tumia wakala au msambazaji wa proksi unaodumishwa na usaidizi wa handaki unaohitajika. Kwa matoleo ya Node yanayolingana, chaguo moja ni fetch ya Undici na ProxyAgent. Hifadhi mfano huu mdogo wa mteja msingi kwa hali ambapo ubadilishanaji wa kawaida wa HTTP wenyewe ndio unaohitaji kudhibiti au kuelewa.

Makala zinazohusiana