Open droe opened 10 years ago
I think to finish this off we need to specify some kind of buffering rules. It would be nice to pass one object to the lua for a request, and another for a response. If we did this unconditionally we could cause lag on the client and huge memory buffers on the server. If we limit based on Content-Length
(libevent's watermarks?), we can achieve something workable, but it only solves for HTTP(s) traffic.
Also, there seems to be something of a bug in the request/responses. The first character of the HTTP request (G in GET, P in POST), seems to be passed seperately to the function.
I was thinking that the lua code should be able to register what it wants to see (requests vs responses, size limit, headers vs body). This is the easy bit. I am still working out how to best refactor HTTP protocol handling out of the libevent read and write handlers and create a more generic data handling core that is able to deal with multiple protocols (#40).
Lua code would then be able to register different hooks depending on the connection type, e.g. for tcp
/ssl
, it could only choose request/response and set size limits, for http
/https
lua callbacks on headers or full bodies would be possible, for smtp
callbacks on full transmitted messages, etc. Of course there need to be considerations wrt size limits, possibly using temp files on disk instead of memory.
The G/ET and P/OST splitting, can you file a separate issue on that, especially if it affects connect logging with http
/https
proxy specs?
Wouldn't a TCP reassembly stack be required to know cross protocol whether a request/response had been completed?
TCP reassembly is handled by the kernel.
We could manually handle it, but it doesn't matter, my train of thought was incorrect.
Implement some flexible and configurable (or even scriptable) way to make modifications to requests and/or responses and possibly allow regex based inclusion/exclusion of certain requests by header matching (client fingerprinting).