Squidetik HTTPS-ra hautatutako HTTP eskaeren birbideratzea
Itzuli bezeroaren birbideratze bat HTTPS gaitasuna duten gune ezagunetarako, HTTP jatorrizko URL guztiak isilpean aldatzea edo proxyak jatorrian TLS laguntza sor dezakeela suposatzea ordez.
Squidek nabigatzaileari hautatutako HTTP URL bat HTTPS bidez berriro saiatzeko eskatu diezaioke. Helmugak dagoeneko baliabide hori HTTPS bidez zerbitzatu behar du; Squid Raspberry Pi batean exekutatzeak ez du gaitasun hori sortzen webgunean.
Squid 7ren url_rewrite_program interfazerako, helper batek bezeroaren birbideratze hau itzul dezake:
OK status=307 url="https://www.example.com/help"Hau bat datozen eskaera baterako helper erantzun ilustratibo bat da, ez helper programa oso bat. Nabigatzaileak birbideratzea jasotzen du eta HTTPS URLra eskaera berria egiten du. Berritze-politikatik kanpoko URL batek OK jaso dezake eta aldatu gabe geratu.
Erabili HTTPS gaitasuna duten helmuga ezagunen zerrenda bat eta analizatu sarrerako URLa. Gorde nahi den bidea eta querya, kontuan hartu portu esplizituak, eta tratatu eskaera metodoak jakinaren gainean. http aurrizki guztiak itsu ordezkatzeak jatorri bakoitzak baliokidea den HTTPS zerbitzua duela suposatzen du.
Helperrak sarrera-lerro bakoitzari instalatutako Squid bertsioaren protokoloarekin erantzun behar dio. Helper kanal paraleloak gaituta badaude, gorde kanalaren identifikatzailea erantzunean. 301:URL adibide biluzi zaharra ez da elkartrukatzen oraingo result-and-key/value formatuarekin.
Aukeratu bezeroaren birbideratzea nabigatzaileak URL berria ezagutu behar duenean. rewrite-url erantzunak, aldiz, Squidi eskatzen dio bezeroaren jatorrizko eskaeraren atzean beste URL bat eskuratzeko, eta horrek aplikazioaren URLak eta egoera koherenteak ez izatea eragin dezake.
Hasierako HTTP eskaera jadanik Squid-era iritsi da helperrak birbideratu aurretik. Politika honek ezin du eskaera hori atzeraeraginez babestu. TLS hurrengo HTTPS konexioan hasten da; CONNECT tunel bakar batek ez du zifratzerik ematen.