I think I sent my previous mail to a bad location, so I'm resending it from nginx list to nginx-devel.
I would like to send a patch for http_log_module which I made for version nginx-1.0.10.
My company is in adserving business and it is important for us to log the big requests with the access_log feature. But we were unable to do that with nginx, because logging all the requests would produce too much I/O load on our servers.
So I made a patch for http_log_module to accept a `size` parameter which is optional (the last parameter after the `buffer`). If this `size` is provided nginx logs only the big enough requests with access_log (checks for `body_bytes_sent`).
I hope you find it useful and you will include this in the upstream.
I have a plugin that uses request.headers_out.headers, I use the
lowcase_key of the element for something. However, recently while debugging
a crash I noticed that the lowcase_key isnt always initialized
set_cookie->lowcase_key isnt set(nor initialized)] I would have taken that
as a bug but noticed that there are other places
[src/http/modules/ngx_http_headers_filter_module.c] where lowcase_key isnt
initialized. However, in all the three instances, header.hash is
initialized to 1.
So, the question is:
1. Does hash = 1 necessarily imply that lowcase_key isnt initialized?
2. Should lowcase_key have been initialized and this is a bug [in which
case I can walk through the code and submit a patch]
3. Why is this done?
During the upcoming days I'm going to try to implement a feature in nginx proxy
that allows disabling local disk buffering/caching of HTTP PUT upload requests,
e.g. allow directly stream the uploads to the backend server.
Right now I'm having problems because nginx proxy stores all the uploads temporarily
to the nginx server local disk, and thus fills up the disk when big files are being uploaded.
If someone has comments/ideas/suggestions about this, feel free to write to me.
I'm currently in the process of getting familiar with nginx code
and the request 'flow' inside nginx.
I'll let you know how it goes :)
on nginx@ list Alexandr wrote that he had implemented something similar,
by simply hijacking connection of the request.
Is there a patch available somewhere?
I've recently written a module to authenticate requests from Akamai's edge server network, based on their G2O, or edge-origin authentication scheme.
The module is finished, however, this being my first nginx module and the fact that I don't spend a lot of time writing in C leads me to ask for a second opinion - how am I doing? Any advice greatly appreciated.
In particular, the module relies on OpenSSL's HMAC and Base64 support. I couldn't find any support for these in nginx core. For now the module simply does not compile without openssl installed. Is this bad?
The following patches restore accept mutex unlock on abnormal process
termination (broken in 1.0.2 with introduction of POSIX semaphores support
in locks) and introduce unlocking of shared memory zone's locks.
This is updated patch series to address some off-list comments from Igor.
- the %uA used insead of %XA to log number of waiting processes;
- separate function used for wakeup after shared mutex unlock (reduces code
duplication, improves code readability);
- separate function used for unlock after process crash (improves code