Hi!
Thanks for your explaination, I read again your lessons on nginx
variable and execution sequence, how nginx works are much clear for me
now.
I change the conf to:
location / {
ssi on;
if $needparse {
set_by_lua $ab ...;
set $http_if_modified_since 0;
}
proxy_set_header If-Modified-Since $http_if_modified_since;
proxy_pass http://django;
}
and it works as what I expect now (when no cookie found, re-do the
ssi; if cookie found, return 304)! Thank you again.
https://groups.google.com/xxxx is blocked by GFW.
Best regards,
Daoyu
On 8/2/12, agentzh <age...@gmail.com> wrote:
> Hello!
>
> On Tue, Jul 31, 2012 at 11:43 PM, daoyu zhuang wrote:
>> I'm using nginx with lua on a/b testing, the conf is attached, the main
>> idea
>> is:
>>
>> if first time user no cookie, set $ab=[randome of a,b,c], also add_header
>> Set-Cookie "ab=$ab"
>> if second time user with cookie, read $cookie_ab, set $ab $cookie_ab;
>>
>> based on the value of $ab, in hello.html, using ssi to include different
>> sub
>> request.
>>
>> This works for normal users, but not for test users (the users who visit
>> once, delete the cookie, and ask for hello.html again). It will result a
>> 304
>> (I guess most request headers are same, except miss some cookie). So the
>> weird thing is test user get a new cookie, but old content. New content
>> only
>> come with ctrl + f5.
>>
>> This may not cause any normal user confuse, but I still wonder whether
>> there
>> are something to told nginx ssi, "if no cookie readed, no cache, do
>> variable
>> substitute".
>>
>
> It seems that you return a Last-Modified response header in the same
> location from your django backend app via ngx_proxy, thus making nginx
> respond to the conditional GET requests from your HTTP clients
> *before* its SSI processor runs. (Why? Because
> ngx_http_not_modified_filter_module runs *before*
> ngx_http_ssi_filter_module!)
>
> Here is a minimized example that can reproduce this:
>
> location = /t {
> set $name 'blah';
> ssi on;
> content_by_lua '
> ngx.header["Last-Modified"] = "Wed, 01 Aug 2012 23:49:31 GMT"
> local resp = [[<!--# echo var="name" default="no" -->]]
> ngx.header.content_type = "text/html"
> ngx.header.content_length = #resp
> ngx.say(resp)
> ';
> }
>
> Then we can test this out like below:
>
> $ curl -i localhost:1984/t
> HTTP/1.1 200 OK
> Server: nginx/1.2.1
> Date: Wed, 01 Aug 2012 18:08:02 GMT
> Content-Type: text/html
> Transfer-Encoding: chunked
> Connection: keep-alive
>
> blah
>
> So far so good, but when we issue a conditional GET, we'll get 304:
>
> $ curl -i -H 'If-Modified-Since: Wed, 01 Aug 2012 23:49:31 GMT'
> localhost:1984/t
> HTTP/1.1 304 Not Modified
> Server: nginx/1.2.1
> Date: Wed, 01 Aug 2012 18:09:43 GMT
> Connection: keep-alive
> Last-Modified: Wed, 01 Aug 2012 23:49:31 GMT
>
> The ngx_ssi module works as an nginx output filter, it will not get a
> chance to run when the ngx_not_modified filter processes the
> conditional GET request.
>
> BTW, you're recommended to use Lua to do the output in addition to
> variable value computing. The SSI thing is very limited in various
> ways :) And sticking with Lua can also make your nginx configurations
> much cleaner and much more maintainable.
>
>> I also notice nginx-dtrace project, is it usable now?
>>
>
> Yes.
>
> BTW, you're *strongly* recommended to send such emails to the
> openresty mailing list directly:
> https://groups.google.com/group/openresty So that other people may
> have a chance to help you as well (or even get help from you ;)).
>
> Also, please edit your email title accordingly when you decide to
> switch the topic. The "Questions about set var NDK" title is very
> confusing for an email that is really talking about SSI.
>
> Best regards,
> -agentzh
>
