Can not use $bytes_sent in module (complex values)

Sun Sep 30 04:19:25 UTC 2012

Hi, Benjamin,

Thu, 27 Sep 2012 17:30:10 +0200 от Benjamin Grössing <mailtogroe at gmail.com>:
>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.
>No wonder, it is just not true. The log module can reference indexed variable in the same way that the rewite module does, but it immediatly outputs its value into the log file. Please excuse me. It seems, for some reason I was trying to explain that it uses unattended indexed variables internally.

>
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.
>Also please have a look at my recent patch. It suggests rather similar but slightly more generalized solution.

Regards,
Vladimir

>
Let me know if I can help any further!
>
>
Regards
>
Benjamin
>
>
2012/9/21 Vladimir Shebordaev <vshebordaev at 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 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
>
>
>
>
>
>
>
> _______________________________________________
>
> 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/20120930/ab307cc1/attachment-0001.html>