Re: 回复： Re: How to bind variable with connection in a customized module?

[Maxim Dounin]

Hello!

(Just a side note: it looks like you mail client have problems 
with proper mail encoding.  I have to recover message headers by 
hand, as the Subject header was split across multiple 
non-consecutive lines, breaking other headers as well.)

On Tue, Jan 22, 2013 at 05:33:31AM -0800, Haifeng Liu wrote:

> Thank you very much. And for your note, I know the connections 
> are reusable, it's not a problem for me. To be sure, during a 
> client is alive, the connection won't serve other clients, is it 
> correct?

This depends on what do you mean by "client".  If next hop http 
client - true, the connection is always with one client.  But on 
the same connection request from different users might appear, 
e.g. if requests are proxied via the same proxy server ("client" 
from nginx point of view).

It might be helpfull to read this section of RFC2616 for better 
understanding:

http://tools.ietf.org/html/rfc2616#section-1.4

> 
> Maxim Dounin <mdounin at mdounin.ru>编写：
> 
> 
> Hello!
> 
> On Tue, Jan 22, 2013 at 08:16:36PM +0800, Liu Haifeng wrote:
> 
> > hi all,
> > 
> > I want save state during a long connection (keep-alive) for 
> > performance optimization in my own HTTP handler module, thus I 
> > can peek up the saved state when handling requests, to speed up 
> > response. Actually it's quite like session concept. I saw 
> > request struct has a member ctx, but what I want is a ctx on the 
> > connection. It seems no way to save any customized variable to 
> > the ngx_connection_t structure. What's the suggested way to make 
> > this if I don't want the client hold something like session_id?
> 
> This was recently discussed on nginx-devel@ mailing list, and 
> probably the best way currently available is to install connection 
> pool cleanup handler with custom data and then iterate over 
> connection pool cleanup handlers to find your data.  It is 
> relatively costly, but allows to keep memory footprint from 
> keepalive connections low and still allows modules to keep their 
> per-connection data in rare cases when they really need to.
> 
> See here:
> http://mailman.nginx.org/pipermail/nginx-devel/2012-December/003049.html
> 
> Note well though, that HTTP is stateless protocol, and the fact 
> that request came from the same connection means mostly nothing: 
> it might be a request from a completely different user.
> 
> -- 
> Maxim Dounin
> http://nginx.com/support.html
> 
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx

-- 
Maxim Dounin
http://nginx.com/support.html