nginx的cookie缓存问题及配置文件研究

其实我很早就在考虑这个问题，nginx既然能缓存，为什么用户和用户间的缓存不会串呢？

直到OpenCDN的用户反馈上来存在用户和用户间的缓存互串问题，我才去研究。

首先，要注意的一点，nginx默认的缓存是不会考虑到cookie的，只根据URI，从配置文件的这条就一目了然了。

我才不会告诉你我本来想用mime类型来控制cache key的，在mime类型是image的时候，cache key不加cookie，而除此之外，cache key加入cookie。于是最要命的一点是prxoy_cache_key这个函数是upstream前执行的（因为毕竟要查缓存是否命中么）。然后这个逻辑就变成了颠倒了因果的逻辑：只有发出包才能获得mime类型，而如果不用cache_key来查缓存就发不出包。

3.奥卡姆剃刀
但是如果是只缓存image等类型的静态文件，这样的话cache-control和expires不就几乎没有用了吗？这个方案还是无法满足我。于是我继续探寻。这个时候才发现，似乎已经无路可走。要么做后花园(方案1)，要么做大公园(方案2)，根据cache-control等header头等来缓存的自助公园呢？(我自己杜撰的名词，不过大家应该可以理解我的意思吧)。
于是开始思路逆行，什么情况下才需要这么纠结于cookie呢？
有用户登录的情况。那么有用户登录的网站又有几类呢？
1.直接用现成的整站方案(Discuz!等)。2.找人或者自己开发的。
如果是第一类网站，需要我们担心吗？不需要！这种网站稳健地很！各种header头一应俱全，不该缓存的页面nginx也是绝对不会缓存的。
如果是第二类网站，需要我们担心吗？需要。那么要那担心什么呢？担心header头不标准吗？不担心！因为这类网站常常什么header都没有，反倒也不会被缓存。那么哪些是需要我们担心的？那些自己做的网站，又输出了错误了的header头，比如在私人页面上面输出缓存标记的。这样的网站多吗？不多！那么既然网站是你写的，解铃还须系铃人。自己乖乖地到CDN上来配你的缓存规则！
那么，还有什么cookie的缓存问题呢？没有了！
那我配置文件需要做什么改动吗？不用做任何改动！直接按照默认的来就行！
那你还让我读到这里，不会一开始就告诉我啊？  
好吧。。我错了。。。