creating a response from the "access" phase

[Hassan Syed]

Hello Folks,

I have spent a few weeks reversing knowledge from Nginx's source base.
However, I need to verify some of my understanding, and I have four
questions for which some help would be extremely usefull. The first question
I have asked on Stack Overflow (SO, link at end of email) . However, I doubt
it will be answered there. The SO question also gives a better overview of
what I am trying to do. I would appreciate if anyone could provide some
advice to that question as I am unlikely to get it on SO.

Now on to questions two and three. My module handler attaches to the
NGX_HTTP_ACCESS_PHASE, and it is designed to generate either a HTTP 302
redirect or an entity body for debugging purposes (more detail in SO
question).

Question two: Simply returning NGX_HTTP_MOVED_TEMPORARILY from the handler
with the requesite response headers set should cause the
"ngx_http_core_access_phase" checker to redirect the connection properly --
am I right ?

Question Three: If I were to generate a response body from the
NGX_HTTP_ACCESS_PHASE should I populate a "ngx_chain_t" and end my handler
with "return ngx_http_output_filter(r, &out);" as shown in
"http/modules/ngx_http_static_module.c" ? will this lead to the desired
behavior, or is this sequence of calls meant only for the
"NGX_HTTP_CORE_CONTENT_PHASE" ?

My fourth and final question (which is related to the first) is about
setting the cache-control headers from the  NGX_HTTP_ACCESS_PHASE. Are there
any ramifications for directly setting this ? What is the best way to do
this ? I would like to prevent any other modules from tampering with this
header once it is set -- am I left at the mercy of the config writer here ?

Many thanks for reading this post, and even more so if you take the time to
reply :D

Regards

Hassan

[SO link]
http://stackoverflow.com/questions/3336923/cache-control-no-cache-mechanism-lowest-common-denominator-behaviour-in-a-sea-of
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx-devel/attachments/20100727/e160fb7f/attachment-0001.html>