pierangelo.masarati(a)polimi.it wrote: > It now comes to my mind that another perhaps less intrusive chance of > intervention could be to act at the *response* level. Think of: > > - the possibility to stack code in the response chain (not necessarily > overlays) > > - have a way to understand if the response originates *before* the > frontend was called > > In this case, the custom code could re-parse the request to re-detect > why it failed and handle it (e.g. log custom information on failure > reason). Not a piece of cake, but probably less intrusive than other > options. (I'm not sure the raw request buffer is still available at > this stage, though.) Still not something useful for slapo-accesslog - we're storing log info as LDAP attributes. We can't store reqDN if the DN has invalid syntax. We can't store reqMod values if the attributetype is unknown or the values are invalid. When a request fails validation it's literally garbage, and toxic - cannot be considered safe to preserve in a DB.