I have requirement to create own cookie based on input and wirte the that
cookie in header.
whenever i need that i can read from header and use it.
I have created my own cookie "thissomevalue" worte in header and later the
same read from header.
Please check my code and let me know why i am not able to read the value
Below code snippet to set header value in request header:-
cookie = ngx_list_push(&r->headers_in.headers);
cookie->lowcase_key = (u_char*) "cookie";
cookie->hash = ngx_crc32_long(cookie->lowcase_key, cookie->key.len);
Below code snippet to read set value from header:-
ngx_str_t val = ngx_string("cookie");
clcf = ngx_http_get_module_main_conf(r, ngx_http_core_module);
key= ngx_hash_key_lc(val.data, val.len);
type = ngx_hash_find(&clcf->headers_in_hash, key, val.data, val.len);
if (type != NULL)
test_val->lowcase_key = (u_char*) "test_val";
test_val->hash = ngx_crc32_long(test_val->lowcase_key, test_val->key.len);
curl response:-Test_val was accepting "somevalue"
HTTP/1.1 200 OK
Date: Tue, 26 Apr 2016 19:13:40 GMT
Hello, This is Nginx test Module!
Thanks & Regards,
I'm currently looking for ideas to resolve a 3rd party module
regression that I keep running into, and figured it would be
best to consult the experts.
The ngx_http_postpone_filter_module is a critical helper for many
modules to ensure subrequests are properly ordered. But I can't seem
to find a proper way to ensure it's included for a 3rd party module.
All of the internal modules which use it have a special declaration in
the auto/modules file enabling postpone, but among the 3rd party
modules there has only ever been crappy workarounds (documentation
saying to enable the SSI module or another which pulls in postpone) or
hacks to add HTTP_POSTPONE_FILTER_SRCS to HTTP_SRCS.
With the new build system introduced in 1.9.11 though,
HTTP_POSTPONE_FILTER_SRCS is no longer exposed to the config file 3rd
party modules use, and we've hit a bit of an impasse. We either need
to pile on increasingly desperate hacks, or we need a better way to
express to the build system when a 3rd party module depends on
One possible solution is to patch the build process to have a
"preconfig" file where modules could override the options specified in
auto/options but it would also give 3rd party modules more room to
mess up variables and break nginx in unexpected ways.
Another option could be to modify the build process to check for
inter-module dependencies being satisfied. So that a module could
specify that it depends on ngx_http_postpone_filter_module and after
all modules were configured, if any dependencies were not enabled,
they would then be configured as well.
So I pose the question: How can we ensure 3rd party modules can pull
in postpone in a future proof way? Is there an obvious solution I'm
overlooking? Or how can the build process be modified to address this?
Some background: enabling AIO threads can result in "stuck" connections,
permanently waiting for handler callback (in the system these connections
appear in a CLOSE_WAIT state). This happens due to race condition(s) in
the AIO thread pool code. Since the window is tiny, it may take hundreds
of thousands of requests on a many-core machine to trigger a single race,
but it is present in the real world: on some systems we accumulate over
a hundred of them a day.
Fix: add a compiler barrier to ngx_unlock(); since it is a macro, it is
subject to the compiler reordering optimisations. Consider the following
fragment of the ngx_thread_pool_cycle() function:
ngx_spinlock(&ngx_thread_pool_done_lock, 1, 2048);
*ngx_thread_pool_done.last = task;
ngx_thread_pool_done.last = &task->next;
On nginx 1.9.14 RHEL 6 build (nginx-1.9.14-1.el6.ngx.x86_64.rpm), you can
see the following assembly code:
438a05: bf 78 f6 70 00 mov $0x70f678,%edi
438a1c: e8 df a6 fe ff callq 423100 <ngx_spinlock>
438a21: 48 8b 05 60 6c 2d 00 mov 0x2d6c60(%rip),%rax
438a28: 48 c7 05 45 6c 2d 00 movq $0x0,0x2d6c45(%rip) # <--
438a2f: 00 00 00 00
438a33: bf b0 8a 43 00 mov $0x438ab0,%edi
438a38: 48 89 2d 49 6c 2d 00 mov %rbp,0x2d6c49(%rip)
438a3f: 48 89 28 mov %rbp,(%rax)
438a42: ff 15 08 72 2d 00 callq *0x2d7208(%rip)
You can see that at 0x438a28 it performs "*lock = 0" before inserting the
task into the queue. This can race with ngx_thread_pool_handler(), where
ngx_thread_pool_done list is reset before the "task" is inserted (that is,
tasks just get lost).
On x86/amd64, the unlock operation only needs a *compiler* barrier, it does
not need a *memory* barrier. I used ngx_memory_barrier() in the patch, but
you can optimise x86/amd64 to use __asm __volatile("":::"memory").
The patch is attached. Even better fix would be to use pthread_spin_lock
or just pthread_mutex_lock. Why roll out your own one?