Hello! [...]
thank you for the response. > Parsing cache validity time from cached responses is used at least > when sending revalidated responses (NGX_HTTP_CACHE_REVALIDATED). > > For cached responses with other cache statuses > (NGX_HTTP_CACHE_HIT, NGX_HTTP_CACHE_STALE) this probably can be > avoided, at least with current code, but it is generally safe, and > avoiding parsing would be at most minor optimization. Further, > such an optimization might not be trivial to maintain, since cache > statuses might be added or changed over time. Just to clarify, I'm not suggesting that parsing is an issue. My concern is updating r->cache->valid_sec (and other variables) while serving a cached object. As the cached object is served (HIT), r->cache->valid_sec is advancing compared to node->valid_sec. > In general, though, updating r->cache->valid_sec from headers > processing functions as currently implemented is wrong, and can Understood, I just wanted to clarify your response about it being "generally safe." > lead to incorrect results when switching to other upstream servers > per proxy_next_upstream after parsing some headers. It should be > either explicitly cleared in ngx_http_upstream_reinit(), or the > parsed value should be kept in u->headers_in till actually used > (so it will be cleared by existing generic code in > ngx_http_upstream_reinit()). Could you please help me understand how ngx_http_upstream_reinit() would be beneficial in the case of a cache HIT? thanks, max
