<div dir="ltr">Thanks Maxim - that does help.<div><br></div><div>I do have a follow up question though, around when to mark variables as <font face="monospace">no_cacheable</font>. </div><div><br></div><div>Looking for instance at the <font face="monospace">request_method</font><font face="arial, sans-serif"> variable</font>, it is set via the <font face="monospace">ngx_http_variable_request_method() </font><font face="arial, sans-serif">function </font>which on success sets <font face="monospace">v->no_cacheable </font>to <font face="monospace">0</font> - that makes sense to me, since it looks at <font face="monospace">r->main->method_name</font> and so I would expect it to be fixed for the lifetime of a request</div><div><br></div><div>However, the declaration of the variable within <font face="monospace">ngx_http_core_variables</font> has the <font face="monospace">NGX_HTTP_VAR_NOCACHEABLE</font> flag set.</div><div><br></div><div>I guess I have two questions here :</div><div><br></div><div>1. it seems like having this variable marked as non-cacheable is unnecessary; in this case, there is little work to be done to set it, but I'm trying to understand the criteria being used - I'd imagine that any variable that is not expected to change over the lifetime of the request should be cacheable - in which case variables like <font face="monospace">msec</font> would be reasonably marked non-cacheable, but I don't see why those like <font face="monospace">request_method</font> would be? It seems similar in scope to me as <font face="monospace">http_host</font> which is <b>not</b> marked non-cachable</div><div><br></div><div>2. is there a reason why the get handler should ever set the variable as non-cacheable, or should it always set it that flag to 0 and instead rely on the call to the <font face="monospace">ngx_http_add_variable()</font> function to set it? (coding style?)<br><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><span><div><br></div><div>Thank you again for your help</div><div><br></div><div>Chris</div></span></div></div></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Apr 5, 2022 at 9:02 AM Maxim Dounin <<a href="mailto:mdounin@mdounin.ru">mdounin@mdounin.ru</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello!<br>
<br>
On Mon, Apr 04, 2022 at 12:44:38PM -0700, Chris Newton via nginx-devel wrote:<br>
<br>
> I'm a little unclear as to when ngx_http_get_flushed_variable() should be<br>
> used rather than ngx_http_get_indexed_variable(). The dev guide is a little<br>
> sparse, so I'm hoping someone could help.<br>
<br>
[...]<br>
<br>
> Are there any guidelines on when ngx_http_get_flushed_variable() should be<br>
> used instead of ngx_http_get_indexed_variable()?<br>
<br>
The ngx_http_get_indexed_variable() does not flush non-cacheable <br>
variables by itself, and should be used when flushes are not <br>
needed and/or handled separately. For example, it is used by the <br>
script codes, and this makes it possible to evaluate multiple <br>
variables with a single cache flush, such as by <br>
ngx_http_script_flush_no_cacheable_variables().<br>
<br>
The ngx_http_get_flushed_variable() does a flush automatically <br>
when needed, that is, it does not use cache for non-cacheable <br>
variables. This is to be used when flushes are not handled <br>
separately and might be important.<br>
<br>
Unless you have some explanation on why using <br>
ngx_http_get_indexed_variable() in the particular place is safe, <br>
you probably should use ngx_http_get_flushed_variable() instead, <br>
or you are risking to end up with incorrect behaviour if you'll <br>
try to lookup non-cacheable variables.<br>
<br>
Just in case, looking through all uses of the <br>
ngx_http_get_indexed_variable() function in nginx:<br>
<br>
- ngx_http_charset_filter_module.c: not sure it is safe, might be <br>
a bug;<br>
<br>
- ngx_http_log_module.c: used with a separate flush by <br>
ngx_http_script_flush_no_cacheable_variables();<br>
<br>
- ngx_http_memcached_module.c: the $memcached_key variable is <br>
expected to be set by "set", so the code assumes no flushes are <br>
needed;<br>
<br>
- ngx_http_userid_filter_module.c: the $uid_reset variables is <br>
expected to be set by "set", so the code assumes no flushes are <br>
needed.<br>
<br>
- ngx_http_variables.c: in the ngx_http_get_flushed_variable() <br>
function, with automatic flush when needed;<br>
<br>
- ngx_http_script.c: used when a flush is handled separately.<br>
<br>
> It seems like it is 'practically never', but why for example does<br>
> ngx_http_get_variable() use<br>
> <br>
> ngx_http_get_flushed_variable()?<br>
<br>
The ngx_http_get_variable() is to be used for dynamic variables <br>
lookup, when you don't know the variable name in advance, notably <br>
in SSI and embedded Perl. It is expected to be used without <br>
external flushes and so uses ngx_http_get_flushed_variable() to <br>
ensure automatic flushes when needed.<br>
<br>
Hope this helps.<br>
<br>
-- <br>
Maxim Dounin<br>
<a href="http://mdounin.ru/" rel="noreferrer" target="_blank">http://mdounin.ru/</a><br>
</blockquote></div>