Paĝo kun URL-kampo estas reta aplikaĵo. Entajpi celon tie petas tiun aplikaĵon akiri kaj prezenti enhavon. Tio estas alia aranĝo ol diri al la retumilo uzi HTTP- aŭ SOCKS-prokurilon.

Ĉe denaska prokura agordo la retumilo daŭre traktas la celan URL-on kiel la retejon. En ordinara retformulara prokurilo la videbla paĝo estas liverata tra la propra URL-skemo kaj deveno de la prokura aplikaĵo. La servo povas reverki ligilojn, skriptojn, kapojn aŭ kuketojn por daŭrigi la navigadon.

KondutoKial la diferenco gravas
Kontroloj de sama devenoLa retumilo taksas la devenon, kiun ĝi efektive ŝargis
Kuketoj kaj alidirektojKonduto de domajno, vojo kaj sekura kunteksto devas kongrui kun la prezentataj URL-oj
Skriptoj konstruantaj novajn URL-ojnPetoj povas eskapi simplan skemon de ligila reverkado
Daŭraj konektoj aŭ WebSocketsLa prokura aplikaĵo bezonas eksplicitan kongruan pritrakton

Tio klarigas konatan rezulton: simpla artikolo ŝarĝiĝas, sed dokumentredaktilo aŭ ensaluta fluo malsukcesas. La malsukceso ne nepre signifas, ke la celo rifuzas la eliran IP de la servo. La peranto eble ne povas konservi la supozojn de la aplikaĵo pri URL-oj kaj retumila sekureco.

Distingvu ankaŭ, kie TLS finiĝas. Servo, kiu akiras kaj republikigas celan enhavon, staras en alia fida pozicio ol ordinara CONNECT-relajso portanta ĉifritan sesion. Vidi HTTPS ĉe la propra adreso de la prokura retejo ne establas TLS-konekton de unu fino al la alia de la retumilo al la originala retejo.

Se la celo estas ordinara retumado tra alia eliro, elektu HTTP- aŭ SOCKS-finpunkton de via servo aŭ el listo de prokuriloj kaj uzu subtenatan denaskan prokuran agordon, kiel la konektagordojn de Firefox. Tio kutime konservas pli da la normala celsemantiko de la retumilo. Retejo kun URL-kampo povas esti intence elektita aplikaĵo, sed ĝi nepre ne prezentu sin kiel la sama interfaco kun malpli da agordo.

Rilataj artikoloj