Response Sent To Wrong User

Hi all,
I’m suffering from the pain that Nginx returns wrong page to the users.
Don’t know if anyone else encountered the same problem.
I have a page summaries.aspx which displays the user summary info for
users. No query string is required, the page just get current user ID
from session, and load the info of this user. Most of the time,
everything works fine. However, if the website is under heavy stress,
Nginx probably would return this page to a wrong user. For example, I’m
[email protected]. If the site is under heavy stress, Iwill see another user’s
summary page.
I’m pretty sure this does not happen in .net side because without nginx
this will not happen.
Could anybody give me some suggestions?

Regards,
Yaoxing

On Thu, Feb 4, 2010 at 4:22 AM, Yaoxing [email protected] wrote:

I’m pretty sure this does not happen in .net side because without nginx
this will not happen.
Could anybody give me some suggestions?

Are you using proxy_cache at all in your nginx configuration?

If so, what are the Expires: and Cache-Control headers being returned
by the IIS back-end server? ASP.NET sets “Cache-Control: private” by
default, but if you override that somehow, the wrong page could be
served to the wrong user.

Also, what version nginx are you using, and on which OS?


RPM

Yes I’m using proxy_cache module, but I configured it not to cache this
summaries.aspx. And most of the time it works. Only under heavy stress
does this bug begin to show up. So I think it might not be a cache
issue. I didn’t change Cache-Control header, it’s set to “Cache-Control:
private” according to what I see in Firebug.
I’m running Nginx 0.7.64 on CentOS 5.

Regards,
Yaoxing

于 2010/2/5 6:10, [email protected] 写道:

On Thu, Feb 4, 2010 at 7:43 PM, Yaoxing [email protected] wrote:

Yes I’m using proxy_cache module, but I configured it not to cache this
summaries.aspx. And most of the time it works. Only under heavy stress does
this bug begin to show up. So I think it might not be a cache issue. I
didn’t change Cache-Control header, it’s set to “Cache-Control: private”
according to what I see in Firebug.
I’m running Nginx 0.7.64 on CentOS 5.

Can you post your nginx config (trimmed of anything sensitive of
course)?

I am interested as I am about to introduce nginx 0.7.65 with
proxy_cache into a high-volume production environment myself, and want
to make sure I won’t experience this same issue. We haven’t seen it
the issue in testing, but our automated load testing tools can’t check
for this case (mis-directed pages). We are also proxying to IIS
running ASP.NET applications.

Are you using the ASP.NET cache at all on the IIS servers?


RPM

On Mon, Feb 8, 2010 at 8:18 PM, Yaoxing [email protected] wrote:

Yes I found it in the cache directory. Seems like a bug of proxy_cache.

It certainly does, unless your “proxy_cache_valid 60m” line was
telling nginx to cache everything for 60m, regardless of the headers
received from the back-end.

Does anybody out there know if the documentation on proxy_cache_valid
is inaccurate or incomplete? Does the proxy_cache_valid settings
override cache-control/Expires headers set by the back-end?

And

I find a solution by changing the last lines to…
I will likely do the same, just to be safe. Essentially, I will omit
all .aspx, .asmx, etc. files from proxy_cache via a separate location.
That will be complicated, though, because of our application layout on
the backend.


RPM

Yes I found it in the cache directory. Seems like a bug of proxy_cache.
And I find a solution by changing the last lines to
location ~* (details.dx)|(products.dx)|(instantbuy.ashx) {
proxy_cache www;
proxy_pass http://cluster;
}
location ~* .(jpg|png|gif|css|js) {
proxy_cache www;
proxy_pass http://cluster;
}
location ~ . {
proxy_pass http://cluster;
}
So that I cache only the specified types and pass all the other requests
to the server. Compare to previously, I pass specified types and cache
all the other types. This ways it works no matter how heavy the stress
is, according to my stress testing. So I put the 2 nginx gateways online
last night. Seems to be alright until now, a lot of 504 though.
If your configuration is similar to mine, I think you’d better change it
this way in case there’s any problem. Let me know if you need the
testing tool I use. It’s written in several hours, shitty but works:)

Regards,
Yaoxing

于 2010/2/9 6:05, [email protected] 写道: