Свързване на HTML услуга за отговори по ICAP със Squid 7

Свържете съществуваща ICAP услуга за отговори с прав прокси Squid 7 и решете кои отговори да се преобразуват.

За прав прокси Squid, който трябва да преобразува HTML отговор, използвайте пътя на адаптацията. Squid обработва прокси заявката на браузъра; ICAP услуга за отговори извършва преобразуването на тялото и връща адаптираното HTTP съобщение.

Това дава на преобразуването определено място в жизнения цикъл на заявката. Правило за заглавка на отговор не може да замени HTML парсер, а отделен филтър на уеб сървър не обработва автоматично трафика, преминаващ през Squid.

Свързване на услуга за отговори

За сборка на Squid 7 с поддръжка на ICAP и съществуваща съвместима услуга формата на конфигурацията е:

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_access избира транзакции за тази услуга. Настройката bypass=0 означава, че Squid не може тихо да пропусне тази услуга, когато приложима транзакция срещне отказ на услугата. Изберете това поведение при отказ според това дали преобразуването е задължително.

Директивите за адаптация зависят от версията. По-конкретно, тези конфигурационни справочници изброяват интерфейсите за ICAP услуга и достъп до адаптация за Squid 7 и по-старите поддържани линии и ги отбелязват като недостъпни в Squid 8. Отнасяйте се към фрагмента като пример за Squid 7, вместо да го копирате в произволно издание.

Дайте на услугата точен договор за преобразуване

Уточнете кои отговори са допустими и какви промени са необходими. Преобразуване само на HTML трябва да оставя изображенията, архивите и несвързаните медии непокътнати. Услугата трябва да обработва и представянето, което действително получава: компресирани тела, кодировки на знаци и метаданните, описващи промененото тяло. Вмъкването на текст в произволни байтове на отговора не е общо преобразуване на HTML.

Обмислете кеширането, когато замяната е специфична за потребителя. Преобразуване преди кеша и споделен кеш са лоша комбинация, ако полученото представяне е валидно само за един читател. Поддържайте съгласувани възможността за кеширане и политиката за преобразуване и спазвайте приложимите директиви no-transform.

И накрая, обикновеният тунел HTTPS CONNECT пренася криптирани байтове. Той не излага HTML на адаптер за отговори. Умишлено управлявана схема за TLS инспекция се нуждае от собствена съвместима настройка и доверие от клиента, преди декриптирани отговори да могат да влязат в този път. Самото правило на ICAP не добавя тази видимост.

Подобни статии