Can not use $bytes_sent in module (complex values)

[Vladimir Shebordaev]

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 at 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 at 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 at nginx.org
>
> http://mailman.nginx.org/mailman/listinfo/nginx-devel
>
>
_______________________________________________
>
nginx-devel mailing list
>nginx-devel at nginx.org
>http://mailman.nginx.org/mailman/listinfo/nginx-devel
>
			
		
		
	

	
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20120921/8a5e3b73/attachment-0001.html>