Distribution EOLE

requête HTTP

2022/12/15 09:21:40.101 kid1| 33,3| client_side_request.cc(272) ~ClientHttpRequest: httpRequestFree: http://www.monip.org/
2022/12/15 09:21:40.101 kid1| 28,3| Checklist.cc(70) preCheck: 0x7ffe15cd57a0 checking fast ACLs
2022/12/15 09:21:40.101 kid1| 28,5| Acl.cc(124) matches: checking access_log syslog:LOG_LOCAL1|LOG_INFO
2022/12/15 09:21:40.101 kid1| 28,5| Acl.cc(124) matches: checking (access_log syslog:LOG_LOCAL1|LOG_INFO line)
2022/12/15 09:21:40.101 kid1| 28,3| Acl.cc(151) matches: checked: (access_log syslog:LOG_LOCAL1|LOG_INFO line) = 1
2022/12/15 09:21:40.101 kid1| 28,3| Acl.cc(151) matches: checked: access_log syslog:LOG_LOCAL1|LOG_INFO = 1
2022/12/15 09:21:40.101 kid1| 28,3| Checklist.cc(63) markFinished: 0x7ffe15cd57a0 answer ALLOWED for match
2022/12/15 09:21:40.101 kid1| 28,4| FilledChecklist.cc(67) ~ACLFilledChecklist: ACLFilledChecklist destroyed 0x7ffe15cd57a0
2022/12/15 09:21:40.101 kid1| 28,4| Checklist.cc(197) ~ACLChecklist: ACLChecklist::~ACLChecklist: destroyed 0x7ffe15cd57a0
2022/12/15 09:21:40.101 kid1| 20,3| store.cc(466) unlock: ClientHttpRequest::loggingEntry unlocking key 7AB5135003278E0DE68887EE322257A4 e:d1@0=sw2p2V/0x55cc02d0bf40*1
2022/12/15 09:21:40.101 kid1| 20,5| store.cc(483) doAbandon: e:d1@0=sw2p2V/0x55cc02d0bf40*0 via ClientHttpRequest::loggingEntry
2022/12/15 09:21:40.101 kid1| 90,3| store_client.cc(805) storePendingNClients: storePendingNClients: returning 0

Il semble y avoir une ACL qui court-circuite le processus.
Aucun message du journal n’est associé à la section 93 qui concerne ICAP (contrairement à ce qui se passe avec une requête HTTPS).

requête HTTP sur monip.org :

2022/12/15 09:43:42 kid1| Starting new ntlmauthenticator helpers...
    current master transaction: master56
2022/12/15 09:43:42 kid1| helperOpenServers: Starting 1/20 'ntlm_auth' processes
    current master transaction: master56
2022/12/15 09:43:42.130 kid1| 93,2| Xaction.cc(330) dieOnConnectionFailure: Adaptation::Icap::OptXact failed to connect to icap://127.0.0.1:1340/request
2022/12/15 09:43:42.130 kid1| 93,2| AsyncJob.cc(129) callException: cannot connect to the ICAP service
    exception location: Xaction.cc(335) dieOnConnectionFailure
2022/12/15 09:43:42.130 kid1| optional ICAP service is down after an options fetch failure: icap://127.0.0.1:1340/request [down,!opt]
    current master transaction: master56
2022/12/15 09:43:42.158 kid1| 93,2| Xaction.cc(330) dieOnConnectionFailure: Adaptation::Icap::OptXact failed to connect to icap://127.0.0.1:1340/response
2022/12/15 09:43:42.159 kid1| 93,2| AsyncJob.cc(129) callException: cannot connect to the ICAP service
    exception location: Xaction.cc(335) dieOnConnectionFailure
2022/12/15 09:43:42.159 kid1| optional ICAP service is down after an options fetch failure: icap://127.0.0.1:1340/response [down,!opt]
    current master transaction: master56

Requête HTTPS sur monip.org

2022/12/15 09:44:12 kid1| optional ICAP service is up: icap://127.0.0.1:1340/request [up]
2022/12/15 09:44:12 kid1| optional ICAP service is up: icap://127.0.0.1:1340/response [up]
2022/12/15 09:44:14 kid1| Starting new ntlmauthenticator helpers...
    current master transaction: master74
2022/12/15 09:44:14 kid1| helperOpenServers: Starting 1/20 'ntlm_auth' processes
    current master transaction: master74
2022/12/15 09:44:14.743 kid1| 93,2| AsyncJob.cc(129) callException: check failed: prime
    exception location: HappyConnOpener.cc(801) maybeGivePrimeItsChance

Les observations précédentes ne sont pas liées au protocole mais plutôt à l’ordre d’exécution.

Dans common.story

# Entry function called by ICAP module to check reqmod
function(icap-checkrequest)
#unless blocked or redirect or connect - leave logging for RESPMOD
if(connect) return icapsslrequestcheck
ifnot(greyset) icap-checkrequest2
if(redirectset) return true
ifnot(blockset) setnolog

En commentant la condition qui applique setnolog, on obtient bien des logs pour les requêtes http.
Le comportement différencié serait à chercher du côté de RESPMOD (quoique ce soit).