ICAP HTML பதில் சேவையை Squid 7 உடன் இணைக்கவும்

HTML பதிலை மாற்ற வேண்டிய Squid முன்னோக்கு ப்ராக்ஸிக்கு adaptation பாதையைப் பயன்படுத்தவும். Squid உலாவியின் ப்ராக்ஸி கோரிக்கையைக் கையாள்கிறது; ICAP பதில் சேவை உடல் மாற்றத்தைச் செய்து தகவமைக்கப்பட்ட HTTP செய்தியைத் திருப்பி அனுப்புகிறது.

இது மாற்றத்திற்கு கோரிக்கையின் வாழ்க்கைச் சுழற்சியில் திட்டவட்டமான இடத்தை அளிக்கிறது. பதில் தலைப்பு விதி HTML பார்சரை மாற்ற முடியாது, தனி வலை சேவையக வடிகட்டி Squid வழியாகச் செல்லும் போக்குவரத்தை தானாக செயலாக்காது.

பதில் சேவையை இணைக்கவும்

ICAP ஆதரவுடன் கூடிய Squid 7 கட்டமைப்பு மற்றும் ஏற்கனவே உள்ள இணக்கமான சேவைக்கு, உள்ளமைவின் வடிவம் இதுவாகும்:

acl adaptation_clients src 192.0.2.0/24

icap_enable on
icap_service html_editor respmod_precache bypass=0 icap://127.0.0.1:1344/modify

adaptation_access html_editor allow adaptation_clients
adaptation_access html_editor deny all

கிளையண்ட் வரம்பும் சேவை URI-யும் எடுத்துக்காட்டுகள். URI பதில் மாற்றத்தைச் செயல்படுத்தும் உண்மையான ICAP சேவையைப் பெயரிட வேண்டும்; /modify என அறிவிப்பது சேவையை உருவாக்காது. இந்தப் பகுதி ப்ராக்ஸியின் ஏற்கனவே உள்ள கேட்பானையும் அணுகல் கட்டுப்பாடுகளையும் நிறைவு செய்கிறது.

respmod_precache தேக்கத்திற்கு முந்தைய புள்ளியில் பதில் adaptation-ஐத் தேர்ந்தெடுக்கிறது. adaptation_access அந்தச் சேவைக்கான பரிவர்த்தனைகளைத் தேர்ந்தெடுக்கிறது. bypass=0 அமைப்பு என்பது பொருந்தும் பரிவர்த்தனை ஒரு சேவை தோல்வியைச் சந்திக்கும்போது Squid இந்தச் சேவையை அமைதியாகத் தவிர்க்க முடியாது என்பதாகும். மாற்றம் கட்டாயமா என்பதைப் பொறுத்து அந்தத் தோல்வி நடத்தையைத் தேர்ந்தெடுக்கவும்.

adaptation வழிமுறைகள் பதிப்பைப் பொறுத்தவை. குறிப்பாக, இந்த உள்ளமைவு குறிப்புகள் Squid 7 மற்றும் முந்தைய ஆதரவு வரிசைகளுக்கான ICAP சேவை மற்றும் adaptation-அணுகல் இடைமுகங்களைப் பட்டியலிட்டு, Squid 8-ல் அவை கிடைக்காது எனக் குறிக்கின்றன. இந்தப் பகுதியை Squid 7-க்கான எடுத்துக்காட்டாகக் கருதுங்கள், எந்த வெளியீட்டிலும் நகலெடுக்க வேண்டாம்.

சேவைக்கு துல்லியமான மாற்ற ஒப்பந்தம் வழங்கவும்

எந்தப் பதில்கள் தகுதியானவை, என்ன மாற்றங்கள் தேவை என்பதைக் குறிப்பிடவும். HTML மட்டும் மாற்றம் படங்கள், காப்பகங்கள் மற்றும் தொடர்பில்லாத ஊடகங்களைத் தொடாமல் விட வேண்டும். சேவை உண்மையில் பெறும் பிரதிநிதித்துவத்தையும் கையாள வேண்டும்: சுருக்கப்பட்ட உடல்கள், எழுத்து குறியாக்கங்கள் மற்றும் மாற்றப்பட்ட உடலை விவரிக்கும் மெட்டாடேட்டா. தன்னிச்சையான பதில் பைட்டுகளில் உரையைச் செருகுவது பொதுவான HTML மாற்றம் அல்ல.

மாற்றீடு பயனர் சார்ந்ததாக இருக்கும்போது தேக்கத்தைக் கவனத்தில் கொள்ளுங்கள். விளைவாக வரும் பிரதிநிதித்துவம் ஒரு வாசகருக்கு மட்டும் செல்லுபடியாகுமானால் precache மாற்றமும் பகிரப்பட்ட தேக்கமும் மோசமான கலவையாகும். தேக்கத் திறனையும் மாற்றக் கொள்கையையும் ஒத்திசைவாக வைத்து, பொருந்தும் no-transform வழிமுறைகளை மதிக்கவும்.

இறுதியாக, சாதாரண HTTPS CONNECT சுரங்கம் மறையாக்கப்பட்ட பைட்டுகளைக் கொண்டு செல்கிறது. அது HTML-ஐ பதில் தகவமைப்பானுக்கு வெளிப்படுத்தாது. வேண்டுமென்றே நிர்வகிக்கப்படும் TLS ஆய்வு ஏற்பாடு, மறைகுறியாக்கப்பட்ட பதில்கள் இந்தப் பாதையில் நுழைவதற்கு முன் அதன் சொந்த இணக்கமான அமைப்பும் கிளையண்ட் நம்பிக்கையும் தேவை. ICAP விதி மட்டும் அந்தத் தெரிவுநிலையைச் சேர்க்காது.