question around ngx_http_get_flushed_variable()

[Maxim Dounin]

Hello!

On Wed, Apr 06, 2022 at 12:01:02PM -0700, Chris Newton via nginx-devel wrote:

> I do have a follow up question though, around when to mark variables as
> no_cacheable.
> 
> Looking for instance at the request_method variable, it is set via the
> ngx_http_variable_request_method()
> function which on success sets v->no_cacheable to 0 - that makes sense to
> me, since it looks at r->main->method_name and so I would expect it to be
> fixed for the lifetime of a request
> 
> However, the declaration of the variable within ngx_http_core_variables has
> the NGX_HTTP_VAR_NOCACHEABLE flag set.
> 
> I guess I have two questions here :
> 
> 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 msec would be reasonably
> marked non-cacheable, but I don't see why those like request_method would
> be? It seems similar in scope to me as http_host which is *not* marked
> non-cachable

The $request_method might need to be different for subrequests, 
and hence non-cacheable.

> 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 ngx_http_add_variable() function to set it?  (coding
> style?)

As long as the variable is marked as NGX_HTTP_VAR_NOCACHEABLE, it 
is ok to simply set the flag to 0 (mostly to initialize the bit 
and simplify the resulting machine code).   Though in some cases 
one may want to mark a particular value returned by the get 
handler as non-cacheable: for example, $content_length is returned 
as non-cacheable for chunked request body till the request body is 
fully read.

-- 
Maxim Dounin
http://mdounin.ru/