Elekeza maombi ya HTTP yaliyochaguliwa kutoka Squid kwenda HTTPS
Rudisha uelekezaji wa mteja kwa tovuti zinazojulikana zenye uwezo wa HTTPS badala ya kubadilisha kwa utulivu kila HTTP origin URL au kudhani kuwa proksi inaweza kuunda usaidizi wa TLS kwenye asili.
Squid inaweza kuomba kivinjari kujaribu tena URL ya HTTP iliyochaguliwa kwa HTTPS. Lengwa lazima liwe tayari linatoa rasilimali husika kwa HTTPS; kuendesha Squid kwenye Raspberry Pi hakuundi uwezo huo kwenye tovuti.
Kwa kiolesura cha url_rewrite_program cha Squid 7, helper inaweza kurudisha uelekezaji wa mteja kama huu:
OK status=307 url="https://www.example.com/help"Hili ni jibu moja la mfano la helper kwa ombi linalolingana, si programu kamili ya helper. Kivinjari hupokea uelekezaji na kufanya ombi jipya kwa URL ya HTTPS. URL iliyo nje ya sera ya uboreshaji inaweza kupokea OK na kubaki bila kubadilika.
Tumia orodha inayojulikana ya malengo yenye uwezo wa HTTPS na uchambue URL inayoingia. Hifadhi njia na query iliyokusudiwa, zingatia bandari zilizo wazi na shughulikia mbinu za maombi kwa uangalifu. Kubadilisha kila kiambishi cha http kwa upofu kunadhani kila asili ina huduma sawa ya HTTPS.
Helper lazima ijibu kila mstari wa pembejeo kwa kufuata itifaki ya toleo la Squid lililowekwa. Ikiwa njia za helper za wakati mmoja zimewashwa, hifadhi kitambulisho cha njia kwenye jibu. Mfano wa zamani wa 301:URL wazi hauwezi kubadilishwa na umbizo la sasa la result-and-key/value.
Chagua uelekezaji wa mteja wakati kivinjari kinapaswa kujua URL mpya. Jibu la rewrite-url badala yake linaomba Squid kuleta URL nyingine nyuma ya ombi la awali la mteja, jambo linaloweza kuacha URL za programu na hali yake zisizolingana.
Ombi la awali la HTTP tayari limesafiri hadi Squid kabla helper haijaelekeza. Sera hii haiwezi kulinda ombi hilo kwa nyuma. TLS huanza kwenye muunganisho ujao wa HTTPS; tunnel ya CONNECT pekee haitoi usimbaji fiche wowote.