Creating a module, I want to read in from config desired http header
fields.
Then, during config still, I want to get the struct offset for the
fields
that have dedicated pointers in the header_in struct. It seems that when
I
access headers_in_hash from the main config, it is uninitialized. I can
see
in the code that there is
in ngx_http.c. It seems to be called when the main conf is being
generated
though I am not certain yet.
Where and when exactly is headers_in_hash initialized? If I wanted to
read
from it during ngx_http_X_merge_loc_conf(), what would I need to do? Or
am
I supposed to do it at some point later?
On Fri, Feb 14, 2014 at 04:39:23PM -0500, atarob wrote:
though I am not certain yet.
Where and when exactly is headers_in_hash initialized? If I wanted to read
from it during ngx_http_X_merge_loc_conf(), what would I need to do? Or am
I supposed to do it at some point later?
The cmcf->headers_in_hash is expected to be initialized during
runtime. As of now, it will be initialized before
postconfiguration hooks, but I wouldn’t recommend relaying on
this.
I also won’t recommend using cmcf->headers_in_hash in your own
module at all, unless you have good reasons to. It’s not really a
part of the API, it’s an internal entity which http core uses to
do it’s work.
access headers_in_hash from the main config, it is uninitialized. I
I also won’t recommend using cmcf->headers_in_hash in your own
module at all, unless you have good reasons to. It’s not really a
part of the API, it’s an internal entity which http core uses to
do it’s work.
There is an API? I thought the only way to figure out nginx was to read
source? But seriously, I didn’t land on any API doing a google search.
API aside, is the point of this hash not to do faster lookups for fields
that become needed at runtime (say from config) as opposed to compile
time?
Otherwise, to look for N fields, I have to do N*M comparisons as I
iterate
through the fields, right? I was trying to avoid that. Is there a better
way?
On Tue, Feb 18, 2014 at 02:36:24PM -0500, atarob wrote:
that have dedicated pointers in the header_in struct. It seems that
generated
postconfiguration hooks, but I wouldn’t recommend relaying on
this.
I also won’t recommend using cmcf->headers_in_hash in your own
module at all, unless you have good reasons to. It’s not really a
part of the API, it’s an internal entity which http core uses to
do it’s work.
There is an API? I thought the only way to figure out nginx was to read
source? But seriously, I didn’t land on any API doing a google search.
API != documentation
API aside, is the point of this hash not to do faster lookups for fields
that become needed at runtime (say from config) as opposed to compile time?
Otherwise, to look for N fields, I have to do N*M comparisons as I iterate
through the fields, right? I was trying to avoid that. Is there a better
way?
The point of this hash is to do special processing of certain
headers in http core. If you want to do something similar in your
own module, you may want to create your own hash.
Creating a module, I want to read in from config desired http
can see
Where and when exactly is headers_in_hash initialized? If I
this.
search.
API != documentation
How true. It’s more fun reading source anyway. What I mean was that it
wasn’t entirely clear to me what I should rely on as “API” and what I
shouldn’t because it might easily change down the road.
The point of this hash is to do special processing of certain
headers in http core. If you want to do something similar in your
own module, you may want to create your own hash.
Fair enough. And thanks for all the hard work.
Ata Roboubi
Posted at Nginx Forum:
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.