On 05/30/2014 01:33 AM, hyc@symas.com wrote:
pierangelo.masarati@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.
Sure. Indeed, it could not be associated with accesslog (invalid DN needs to be detected way before a database can be selected). Such a case would belong to some "debugging" layer (e.g. client-server interaction troubleshooting), which BTW I'm convinced the current logging is more than enough for.
p.