# Fastcgi\_cache\_key and empty $content\_type in cache

**URL:** <https://www.ruby-forum.com/t/fastcgi-cache-key-and-empty-content-type-in-cache/206377>\
**Category:** NGINX\
**Created:** [April 29, 2011, 12:23pm UTC](https://www.ruby-forum.com/t/fastcgi-cache-key-and-empty-content-type-in-cache/206377 "2011-04-29T12:23:21Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![dubstep](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/cdc98d/32.png) [@dubstep](https://www.ruby-forum.com/u/dubstep)\
**Post date:** [April 29, 2011, 12:23pm UTC](https://www.ruby-forum.com/t/fastcgi-cache-key-and-empty-content-type-in-cache/206377/1 "2011-04-29T12:23:21Z")

</div>

Have a strange behavior of fastcgi cache, the variable $content\_type  
does not passes to the cache KEY, configuration:  
…  
location ~ .php$ {  
fastcgi\_cache cache;  
fastcgi\_cache\_key  
“$content\_type|$request\_method|$is\_args|$host|$request\_uri|$http\_referer”;  
fastcgi\_cache\_valid any 60m;  
fastcgi\_cache\_use\_stale error timeout invalid\_header http\_500  
http\_503;  
fastcgi\_ignore\_headers “Set-Cookie” “Cache-Control” “Expires”;  
fastcgi\_pass\_header “Set-Cookie”;

```
    fastcgi_pass 127.0.0.1:8000;
    fastcgi_index index.php;
    fastcgi_connect_timeout 60;
    fastcgi_send_timeout 180;
    fastcgi_read_timeout 180;
    fastcgi_buffers 4 128k;

    fastcgi_buffer_size 128k;

    fastcgi_intercept_errors on;

    fastcgi_param SCRIPT_FILENAME

```

$document\_root$fastcgi\_script\_name;  
fastcgi\_param REMOTE\_USER $remote\_user;  
fastcgi\_param QUERY\_STRING $query\_string;  
fastcgi\_param REQUEST\_METHOD $request\_method;  
fastcgi\_param CONTENT\_TYPE $content\_type;  
fastcgi\_param CONTENT\_LENGTH $content\_length;  
fastcgi\_param SCRIPT\_NAME $fastcgi\_script\_name;  
fastcgi\_param REQUEST\_URI $request\_uri;  
fastcgi\_param DOCUMENT\_URI $document\_uri;  
fastcgi\_param DOCUMENT\_ROOT $document\_root;  
fastcgi\_param SERVER\_PROTOCOL $server\_protocol;  
fastcgi\_param GATEWAY\_INTERFACE CGI/1.1;  
fastcgi\_param SERVER\_SOFTWARE nginx/$nginx\_version;  
fastcgi\_param REMOTE\_ADDR $remote\_addr;  
fastcgi\_param REMOTE\_PORT $remote\_port;  
fastcgi\_param SERVER\_ADDR $server\_addr;  
fastcgi\_param SERVER\_PORT $server\_port;  
fastcgi\_param SERVER\_NAME $server\_name;

```
    fastcgi_param SCRIPT_FILENAME

```

/var/www/site\_folder$fastcgi\_script\_name;  
}  
…

But when I look into cache-file, the KEY field does not contain the  
content-type:  
…  
KEY:  
|GET|?|site\_name|/system/files/imagecache/50x50/iconimage.png|http://site\_name/  
…  
Content-Type: image/png  
…

As you see the content-type is visible in cache-file body, but it is not  
visible in the KEY field, it’s just empty there. Does anybody knows why  
this happens?

Thank you for your advices.

Posted at Nginx Forum:

> **[fastcgi\_cache\_key and empty $content\_type in cache](https://forum.nginx.org/read.php?2,194424,194424#msg-194424)**
>
> Have a strange behavior of fastcgi cache, the variable $content\_type does not passes to the cache KEY, configuration: ..... location ~ \\.php$ { fastcgi\_cache cache; fastcgi\_cache\_key...

---

<div class="post-metadata">

**Author:** ![namesys](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/ed655f/32.png) [@namesys](https://www.ruby-forum.com/u/namesys)\
**Post date:** [April 29, 2011, 3:33pm UTC](https://www.ruby-forum.com/t/fastcgi-cache-key-and-empty-content-type-in-cache/206377/2 "2011-04-29T15:33:39Z")

</div>

Hello!

On Fri, Apr 29, 2011 at 06:22:39AM -0400, namesys wrote:

> Have a strange behavior of fastcgi cache, the variable $content\_type  
> does not passes to the cache KEY, configuration:

[…]

> visible in the KEY field, it’s just empty there. Does anybody knows why  
> this happens?

Content-Type header you see in body is response content type  
(available as $upstream\_http\_content\_type variable). It can’t be  
used in cache key though as it’s not known before we have a  
response.

Variable $content\_type is _request_ content type. It’s empty in  
most cases as requests usually doesn’t have any content.

Maxim D.