Kan Squid se URL-herskrywer reaksieliggame verander?
Hou die keuse van versoek-URL's apart van reaksie-aanpassing en TLS-ontsleuteling wanneer jy 'n vorentoe-volmagtigde uitbrei.
url_rewrite_program werk op versoek-URL-besluite. Dit ontvang versoekinligting en antwoord via Squid se helper-protokol; dit ontvang nie 'n afgelaaide lêer om te wysig en terug te stuur nie.
| Verlangde bewerking | Relevante grens |
|---|---|
| Herlei die blaaier of kies 'n ander versoek-URL | Die URL-herskrywingshelper se rol in die versoekfase |
| Verander 'n sigbare HTTP-reaksieliggaam | 'n Fasiliteit vir reaksie-aanpassing, soos gekonfigureerde ICAP-reaksiewysiging |
| Lees HTTP binne gewone CONNECT | Die bestemming se TLS moet eers beëindig word onder 'n gepaste ontplooiingsreëling |
| Ontsleutel 'n toepassing-versleutelde lêer | Die lêer se formaat, algoritme en sleutel, ongeag hoe dit vervoer word |
Die laaste twee rye is maklik om te verwar. 'n Gewone lêer wat oor HTTPS vervoer word, word deur TLS beskerm. 'n Toepassing-versleutelde lêer kan versleutel bly selfs nadat HTTPS beëindig is. Om 'n aanpassingskoppelvlak te kies, verskaf nóg die toepassing se sleutel nóg sy ontsleutelingsalgoritme.
Gewone CONNECT stuur versleutelde tonnelgrepe deur. 'n URL-helper stel nie die binneste reaksie bloot nie; 'n ontwerp wat inspeksie vereis, moet vasstel of daardie verkeer in die ontplooiing ontsleutel kan en moet word.
Waar Squid die HTTP-boodskap kan inspekteer, bly 'n diens vir reaksiewysiging steeds verantwoordelik vir inhoud-enkoderings, veranderde lengtes en foutgedrag. Kies die koppelvlak nadat die transformasie gedefinieer is, eerder as om 'n werkende voorbeeld van URL-herskrywing uit te brei na 'n verwerkingsfase wat dit nooit ontvang nie.