Endurbeina völdum HTTP-beiðnum frá Squid yfir á HTTPS
Skilaðu biðlaraendurbeiningu fyrir þekkta HTTPS-færa vefi í stað þess að breyta hljóðlega hverri HTTP-uppruna-URL eða gera ráð fyrir að proxy geti búið til TLS-stuðning á upprunanum.
Squid getur beðið vafra um að reyna valda HTTP-URL aftur yfir HTTPS. Áfangastaðurinn verður þegar að þjóna viðkomandi tilfangi yfir HTTPS; að keyra Squid á Raspberry Pi skapar ekki þá getu á vefnum.
Fyrir url_rewrite_program viðmót Squid 7 getur helper skilað biðlaraendurbeiningu eins og þessari:
OK status=307 url="https://www.example.com/help"Þetta er eitt dæmigert helper-svar fyrir samsvarandi beiðni, ekki heil helper-forrit. Vafrinn tekur við endurbeiningunni og sendir nýja beiðni á HTTPS-URLið. URL utan uppfærslustefnunnar getur fengið OK og verið óbreytt.
Notaðu þekktan lista yfir HTTPS-færa áfangastaði og greindu innkomandi URL. Varðveittu ætlaða slóð og query, reiknaðu með skýrum pörtum og meðhöndlaðu beiðniaðferðir af ásetningi. Að skipta blindandi út hverri http-forskeyti gerir ráð fyrir að hver uppruni hafi jafngilda HTTPS-þjónustu.
Helper verður að svara hverri inntakslínu samkvæmt samskiptareglum uppsettrar Squid-útgáfu. Ef samhliða helper-rásir eru virkar skal varðveita rásarauðkennið í svarinu. Gamla bert 301:URL dæmið er ekki skiptanlegt við núverandi result-and-key/value snið.
Veldu biðlaraendurbeiningu þegar vafrinn á að þekkja nýja URLið. rewrite-url svar biður þess í stað Squid að sækja annað URL bak við upprunalegu beiðni biðlarans, sem getur látið URL forritsins og stöðu þess vera ósamkvæm.
Upprunalega HTTP-beiðnin er þegar farin til Squid áður en helper getur endurbeint henni. Þessi stefna getur ekki varið þá beiðni afturvirkt. TLS hefst á næstu HTTPS-tengingu; CONNECT-göng ein og sér veita enga dulkóðun.