memcached HTTP 304 patch

Vicente Aguilar bisente at
Tue Nov 17 09:33:29 MSK 2009


>> - a memcached patch that stores the current epoch on the flags 
>> field when storing a new key-value pair. IMPORTANT: whatever 
>> flags the client tries to set get lost, as the server overwrites them 
>> with the current timestamp!!
> Isn't it better to tell ngx_memcached to set the flags field and avoid
> patching the memcached server?

But nginx isn't the one setting the values on memcached, that's the app running on tomcat. Anyway I guess we could take a look at the flags on the first access to a key and if the field is uninitialized (0) set it to the current timestamp. But that wouldn't be the real modification time of that page, but that of the second access to it (fist time memcached misses and nginx passes control to tomcat who sets the value, second time the page is served from memcached). Wouldn't really make a difference, I guess. It would work. Anyway I don't like nginx setting it, nginx is the one serving it, not producing it.

Another less intrusive option is not modifying memcached and having the developers set the timestamp on the flags everytime they store something on memcached (or patch the library they use to access it). Quite easy to do, we could just overload the method they use to store stuff on memcached and set the timestamp there. But right now I wanted something automatic, something I could test without changing our app's code.


 Vicente Aguilar <bisente at> |

More information about the nginx mailing list