Hello,

thanks for your further explanations. I think I understand the
concepts of these variables and how they are calculated now. However,
I am not sure how calling nxg_http_add_variable and implementing that
specific getter would affect performance for modules (other than the
log module) using it.

I have also had a look at the changeset 4686, adding the $status
variable. Thats exactly what I had in mind! Since $body_bytes_sent
already exists (it actually just subtracts the header length from the
total length!), adding $bytes_sent is actually quite easy (or did I
miss something?).

I have attached a patch (based on nginx 1.3.6) that adds $bytes_sent
to ngx_http_variables. It works great for me - I'd be happy to see it
in a future nginx release.

Let me know if I can help any further!

Regards
Benjamin

2012/9/21 Vladimir Shebordaev <vshebordaev@mail.ru>:
> Benjamin,
>
> it seems I used not quite neat wording, so my earlier explanations might
> look obfuscating.
>
> Basically, the indexed variable is any "automatic" variable referenced thow
> the request->variables array. The variables of the current log module do use
> index slots, so they always have space for the value preallocated in
> ngx_http_init_request(). But those variables can be referenced from a script
> or by another module neither by name since they are missing from
> cmcf->variables_hash, nor by index, e.g. by a complex value, since they
> have no getter method thus are rejected in ngx_http_variables_init_vars() as
> unknown.
>
> If you modify the log module to register its variables with
> nxg_http_add_variable() and implement correct get handlers, they would
> surely be available everywhere like any other variable. For performance
> reasons the log module in itself should still use its variables as indexed
> ones, since log operations are expensive and rather frequent. If you
> implement the generic getter method for the http variable infrastructure,
> you might immediatly use it in the log module handler probably using their
> own machinery.
>
> Hope it helps.
>
> Regards,
> Vladimir
>
>
>
>
> Wed, 19 Sep 2012 23:11:57 +0200 от Benjamin Grössing <mailtogroe@gmail.com>:
>
> Hi Vladimir, hi Maxim!
>
>
> Thanks for your answers. I've had a look at the rewrite module -
> unfortunately it does not support the $bytes_sent variable either as
> configuring "if ($bytes_sent) { }" throws the error: [emerg] unknown
> "bytes_sent" variable.
>
> Nice to hear that there is a plan to include all variables in the
> complex value system - I think that would make that part a of nginx a
> lot more clear! I'd be happy if I could contribute here, but I am not
> sure about the details. Is there any guide to contributing to nginx
> available or do I just have to create a patch file and post it here?
> Can I just start with the nginx 1.2.3 source code from nginx.org?
>
> Regards
> Benjamin
>
> 2012/9/19 Maxim Dounin <mdounin@mdounin.ru>:
>> Hello!
>>
>> On Tue, Sep 18, 2012 at 03:55:38PM +0200, Benjamin Grössing wrote:
>>
>>> Hello,
>>>
>>> I am currently working on a nginx module, that parses user defined
>>> strings for variables using ngx_http_complex_value_t. That works great
>>> with all variables defined in ngx_http_variables.c (i.e.
>>> $body_bytes_sent). However, variables as $bytes_sent do not exist here
>>> since ngx_http_log_module uses its own variable parsing system. What
>>> is the best way to use these extra variables in my module? I have
>>> thought of the following options, I am not very sure about what is the
>>> best way to go:
>>> a) Copy the ngx_http_log_module code in my own module and rename every
>>> single type and function to avoid double definitions. Reuse functions
>>> and types from there.
>>> b) Move the ngx_http_log_module code in my own module directory and
>>> compile it only there. Reuse functions and types from there.
>>> c) Write own variable parsing system, reuse a few snippets from
>>> ngx_http_variables and ngx_http_log_module, whatever fits best.
>>> d) Use complex values and try to extend the ngx_http_core_variables
>>> array to include $body_bytes_sent and the other missing variables (I
>>> don't understand why they are not included here anyway?).
>>> e) Any better way to achieve that?
>>>
>>> I'd really appreciate your help.
>>
>> All variables that are currently present only in log module should
>> really be made available as normal variables as well. They aren't
>> yet mostly due to historical reasons (log module appeared before
>> normal variables were implemented) and the fact that most of
>> them are only usable for logging.
>>
>> No idea what would be best for your particular module, but in
>> general it's better to use complex values and what's available via
>> normal variables. Unless you need $bytes_sent right now - it's
>> probably the best aproach, and missing variables will be available
>> once they appear in nginx.
>>
>> (The latter is something you may speedup by submitting a good
>> patch. Most tricky part here would be to follow coding style.)
>>
>> Maxim Dounin
>>
>> _______________________________________________
>> nginx-devel mailing list
>> nginx-devel@nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-devel
>
> _______________________________________________
> nginx-devel mailing list
> nginx-devel@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel
>
>
>
> _______________________________________________
> nginx-devel mailing list
> nginx-devel@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel
_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel