# Memcached HTTP 304 patch **URL:** \ **Category:** NGINX\ **Created:** [November 16, 2009, 8:58pm UTC](https://www.ruby-forum.com/t/memcached-http-304-patch/179061 "2009-11-16T20:58:31Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![Vicente\_A](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/v/fbc32d/32.png) [@Vicente\_A](https://www.ruby-forum.com/u/Vicente_A)\ **Post date:** [November 16, 2009, 8:58pm UTC](https://www.ruby-forum.com/t/memcached-http-304-patch/179061/1 "2009-11-16T20:58:31Z")
Hi everyone I’m new to the list, have looked for something like this but couldn’t find it. Sorry if there’s a patch like this already. I’m working on the server architecture for a new web portal. It’s going to be Amazon-EC2 based and will have a nginx front end to several tomcat back end servers. The nginx servers will proxy-cache some dynamic pages (search results, internal web-services queries) and will also have a static page cache based on memcached. While starting to roll memcached into the solution I noticed that I stoped receiving HTTP 304 responses, everything served off memcached where 200. After digging a little bit on Google I found out it was the expected behavior as memcached doesn’t store the timestamp (last-modified) of the files. So I’ve given it a try and developed a quick patch. There are two parts to the patch: - 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!! - a nginx patch to properly set the “last-modified” HTTP header according to the memcached-stored flags (timestamp). The patches have been tested with nginx 0.7.62 and memcached 1.2.2. I’ve been testing it this morning at work and seems to work as expected, will do more extensive tests tomorrow. I’m quite puzzled at the simplicity of the patch, as I didn’t need to code the logic to check if the cached page is more recent than the client’s one and return 302 or 200. After successfully returning the last-modified header from memcached, nginx seems to do the rest of the job somewhere on its own! In fact the ims variable on the patch is never used. I’m not familiar with nginx source code, today is the first day I’ve looked into it, so maybe this was expected behavior. Could someone more experienced on nginx internals confirm this? If anyone gives this a try, please let me know your experiences. Regards ---
**Author:** ![Vicente\_A](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/v/fbc32d/32.png) [@Vicente\_A](https://www.ruby-forum.com/u/Vicente_A)\ **Post date:** [November 17, 2009, 4:46am UTC](https://www.ruby-forum.com/t/memcached-http-304-patch/179061/2 "2009-11-17T04:46:10Z")
On Tue, Nov 17, 2009 at 3:52 AM, Vicente A. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > There are two parts to the patch: > > - 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? Cheers, -agentzh ---
**Author:** ![Vicente\_A](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/v/fbc32d/32.png) [@Vicente\_A](https://www.ruby-forum.com/u/Vicente_A)\ **Post date:** [November 17, 2009, 7:37am UTC](https://www.ruby-forum.com/t/memcached-http-304-patch/179061/3 "2009-11-17T07:37:41Z")
Hi > > - 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. Regards ---
**Author:** ![Vicente\_A](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/v/fbc32d/32.png) [@Vicente\_A](https://www.ruby-forum.com/u/Vicente_A)\ **Post date:** [November 17, 2009, 8:57am UTC](https://www.ruby-forum.com/t/memcached-http-304-patch/179061/4 "2009-11-17T08:57:17Z")
On Tue, Nov 17, 2009 at 2:33 PM, Vicente A. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > But nginx isn’t the one setting the values on memcached, that’s the app running on tomcat. _nod_ Was assuming you were using ngx\_memcached in your app to _set_ values too, because I had been thinking seriously about adding set/add/replace/delete/cas/incr/decr/etc support to ngx\_memcached 😛 Sorry about that. Thanks for making this clear 🙂 Cheers, -agentzh