Selektearre HTTP-fersiken fan Squid nei HTTPS trochstjoere
Stjoer in client-trochstjoering werom foar bekende HTTPS-geskikte siden ynstee fan stilwei elke HTTP-oarsprong-URL te feroarjen of oan te nimmen dat de proxy TLS-stipe by de oarsprong meitsje kin.
Squid kin in browser freegje om in selektearre HTTP-URL opnij te besykjen fia HTTPS. De bestimming moat de byhearrende boarne al fia HTTPS leverje; Squid op in Raspberry Pi draaie makket dy mooglikheid net op 'e website.
Foar de url_rewrite_program-interface fan Squid 7 kin in helper in client-trochstjoering weromstjoere lykas dizze:
OK status=307 url="https://www.example.com/help"
Dit is ien yllustraasje fan in helper-antwurd foar in oerienkommende fersyk, gjin folslein helper-programma. De browser ûntfangt de trochstjoering en docht in nij fersyk nei de HTTPS-URL. In URL bûten it opwurdearringsbelied kin OK krije en ûnferoare bliuwe.
Brûk in bekende list fan HTTPS-geskikte bestimmingen en parsear de ynkommende URL. Behâld it bedoelde paad en de query, hâld rekken mei eksplisite poarten en behannelje fersykmethoden bewust. Elk http-foarheaksel blyn ferfange giet derfan út dat elke oarsprong in lykweardige HTTPS-tsjinst hat.
De helper moat elke ynfierrigel beantwurdzje neffens it protokol fan 'e ynstallearre Squid-ferzje. As parallelle helper-kanalen ynskeakele binne, behâld dan de kanaalidentifikaasje yn it antwurd. It âlde keale 301:URL-foarbyld is net útwikselber mei it hjoeddeiske result-and-key/value-formaat.
Kies in client-trochstjoering as de browser de nije URL witte moat. In rewrite-url-antwurd freget Squid ynstee om in oare URL efter it oarspronklike fersyk fan 'e klant op te heljen, wat URL's en steat fan 'e applikaasje ynkonsistint litte kin.
It earste HTTP-fersyk is al nei Squid reizge foardat de helper it trochstjoere kin. Dit belied kin dat fersyk net efterôf beskermje. TLS begjint op 'e folgjende HTTPS-ferbining; in CONNECT-tunnel allinnich biedt gjin fersifering.