Custom response codes and content-types for memcache module

[Spil Games]

Hi Maxim, thanks for your feedback.


> This part looks plain wrong for me.  If there is no data in
> memcached - it's 404 Not Found, not 503 Service Unavailable.

I dare to challenge that. At least when it comes to returning such an 
HTTP response code back to clients. Memcached is a cache and so 
ultimately does not know if an object exists or not. It only knows 
whether it's currently available.

Consider a site which is almost fully served from memcached. Now what 
happens if we flush the cache? Should we return 404's? What about search 
engines? They will remove the pages from the index because we say the 
page does not exist. IMO in most situations the memcache module should 
indicate a temporary unavailability instead of a permanent one.

I agree that hardcoding it to 503 is not a good option too. What if I'd 
make it configurable and let it default to 404?


> Something other should be used to distinguish between 404 stored in
> memcached and 404 generated due to key not found in memcached.

That's another option. A variable could be set for example, but that may 
be even more a hack than above. Syntacticly it would be a challenge too. 
I don't think this is allowed in the current syntax:

if ($memcached_not_found) {
  error_page 404 = /not_found_handler$request_uri;
}

Just making the memcached_not_found response code configurable would be 
better IMO. What do you think?


> Why not just reuse upstream functionality as fastcgi/proxy modules
> do?

Because I'm not an experienced Nginx hacker. ;-) But I appreciate the 
hint.

I don't fully understand what's going on with the 
'upstream.pass_request_headers' in the fastcgi and proxy modules, but 
ofcourse it would be a better approach to reuse than to reinvent. I will 
have a look and see if I can do that.

-- 
Posted via http://www.ruby-forum.com/.