nginx serving wrong website under proxy_cache

[Jim Ohlstein]

Igor Sysoev wrote:
> On Sun, May 03, 2009 at 03:15:33AM -0400, Jim Ohlstein wrote:
>
>   
>> Igor Sysoev wrote:
>>     
>>> On Sun, May 03, 2009 at 02:05:57AM -0400, Jim Ohlstein wrote:
>>>
>>>  
>>>       
>>>> Igor Sysoev wrote:
>>>>    
>>>>         
>>>>> On Sun, May 03, 2009 at 01:18:30AM -0400, Jim Ohlstein wrote:
>>>>>
>>>>>
>>>>>      
>>>>>           
>>>>>> Igor Sysoev wrote:
>>>>>>   
>>>>>>        
>>>>>>             
>>>>>>> On Sat, May 02, 2009 at 11:16:47PM -0400, Jim Ohlstein wrote:
>>>>>>>
>>>>>>>
>>>>>>>     
>>>>>>>          
>>>>>>>               
>>>>>>>> Correction:
>>>>>>>>
>>>>>>>> The question should read:
>>>>>>>>
>>>>>>>> Do I need to use two fastcgi_cache_key settings if a site serves both 
>>>>>>>> http and https?
>>>>>>>>  
>>>>>>>>       
>>>>>>>>            
>>>>>>>>                 
>>>>>>> If you use the same backend - no:
>>>>>>>
>>>>>>>    server {
>>>>>>>        listen 80;
>>>>>>>        location / {
>>>>>>>            fastcgi_pass       backend:9000;
>>>>>>>            fastcgi_cache_key  backend:9000$request_uri;
>>>>>>>        }
>>>>>>>    }
>>>>>>>
>>>>>>>    server {
>>>>>>>        listen 443;
>>>>>>>        location / {
>>>>>>>            fastcgi_pass       backend:9000;
>>>>>>>            fastcgi_cache_key  backend:9000$request_uri;
>>>>>>>        }
>>>>>>>    }
>>>>>>>
>>>>>>>
>>>>>>>     
>>>>>>>          
>>>>>>>               
>>>>>> I am using the same backend and configured like this:
>>>>>>
>>>>>> server {
>>>>>>  listen  80;
>>>>>>
>>>>>>  location / {
>>>>>>      fastcgi_pass backend;
>>>>>>      fastcgi_cache one;
>>>>>>      fastcgi_cache_key backend$request_uri;
>>>>>>  }
>>>>>> }
>>>>>>
>>>>>> server {
>>>>>>  listen     443;
>>>>>>  location / {
>>>>>>      fastcgi_pass backend;
>>>>>>      fastcgi_cache one;
>>>>>>      fastcgi_cache_key backend$request_uri;
>>>>>>  }
>>>>>> }
>>>>>>   
>>>>>>        
>>>>>>             
>>>>> Yes, this is OK.
>>>>>
>>>>>
>>>>>      
>>>>>           
>>>>>> For what it may be worth, I have seen some md5 collisions in the error 
>>>>>> log:
>>>>>>
>>>>>> 2009/05/03 00:39:18 [crit] 21997#0: *61 cache file 
>>>>>> "/usr/local/nginx/cache/0/da/90e8de013d4126fbab247d12350fdda0" has md5 
>>>>>> collision, client: my.ip.addr.ess, server: mydomain.com, request: "GET 
>>>>>> /rtwhtrsyrn/010110A/687474702s7777772r777732746s7073697465732r636s6q2s627574746s6r2r7068703s753q776s726p6477617274776s7n6s6r655s636s6q 
>>>>>> HTTP/1.1", host: "mydomain.com", referrer: 
>>>>>> "https://mydomain.com/rtwhtrsyrn/010110A/687474702s776s726p6477617274776s7n6s6r652r636s6q2s666s72756q732s616r6r6s756r63656q656r74732s31333535392q6r6s2q796s752q6172656r742q6372617n792r68746q6p"
>>>>>> 2009/05/03 00:39:24 [crit] 21997#0: *44 cache file 
>>>>>> "/usr/local/nginx/cache/0/da/90e8de013d4126fbab247d12350fdda0" has md5 
>>>>>> collision, client: my.ip.addr.ess, server: mydomain.com, request: "GET 
>>>>>> /rtwhtrsyrn/010110A/687474702s7777772r777732746s7073697465732r636s6q2s627574746s6r2r7068703s753q776s726p6477617274776s7n6s6r655s636s6q 
>>>>>> HTTP/1.1", host: "mydomain.com", referrer: 
>>>>>> "https://mydomain.com/rtwhtrsyrn/010110A/687474702s776s726p6477617274776s7n6s6r652r636s6q2s666s72756q732s2r2r2s"
>>>>>>   
>>>>>>        
>>>>>>             
>>>>> nginx uses md5 create a cache key and use the key as path to a cache 
>>>>> file,
>>>>> 90e8de013d4126fbab247d12350fdda0 in you case. Besides, in the file there
>>>>> is crc32 of the original key to test possible md5 collisions.
>>>>>
>>>>> Could you run
>>>>>
>>>>> head -1 /usr/local/nginx/cache/0/da/90e8de013d4126fbab247d12350fdda0 | 
>>>>> hexdump
>>>>> head -2 /usr/local/nginx/cache/0/da/90e8de013d4126fbab247d12350fdda0 | 
>>>>> tail -1
>>>>>
>>>>> ?
>>>>>
>>>>>
>>>>>
>>>>>      
>>>>>           
>>>> [root at saturn logs]# head -1 
>>>> /usr/local/nginx/cache/0/da/90e8de013d4126fbab247d12350fdda0 | hexdump
>>>> 0000000 8ab0 1afc 0000 0000 1a20 b835 0032 0000
>>>> 0000010 0000 0000 0000 0000 0000 0000 0000 0000
>>>> 0000020 028b 0000 0000 0000 000a              
>>>> 0000029
>>>> [root at saturn logs]# head -2 
>>>> /usr/local/nginx/cache/0/da/90e8de013d4126fbab247d12350fdda0 | tail -1
>>>> KEY: 
>>>> unix:/tmp/cgi.sock.1:/rtwhtrsyrn/010110A/687474702s7777772r777732746s7073697465732r636s6q2s627574746s6r2r7068703s753q776s726p6477617274776s7n6s6r655s636s6q
>>>>    
>>>>         
>>> It's seems like nginx bug. Could you create debug log ?
>>>
>>>
>>>  
>>>       
>> I'm sure I could... if only I knew how. :)
>>
>> Can you please give me the steps you want me to take?
>> It will have to wait a few hours. It's ~ 0315 here and I'm going to bed.
>>     
>
> ./configure --with-debug ...
>
> nginx.conf:
>
> error_log /path/to/log  debug;
>
> or, if you can easy reproduce the bug with single request:
>
> events {
>      debug_connection  your.ip.address;
> }
>
>
>   

I reproduced the error:

2009/05/03 15:34:05 [crit] 4845#0: *178 cache file 
"/usr/local/nginx/cache/0/da/90e8de013d4126fbab247d12350fdda0" has md5 
collision, client: 96.238.94.155, server: mydomain.com, request: "GET 
/rtwhtrsyrn/010110A/687474702s7777772r777732746s7073697465732r636s6q2s627574746s6r2r7068703s753q776s726p6477617274776s7n6s6r655s636s6q 
HTTP/1.1", host: "mydomain.com"

I did it shortly after a restart as the error log using debug got very 
large very fast.

The relevant portion is attached. If you want to see the full 5.6M file 
I can put it in a location where it can be downloaded. Just let me know.

Jim




-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: error.txt
URL: <http://nginx.org/pipermail/nginx/attachments/20090503/b353bafb/attachment.txt>