For the last couple of days I have been implementing ETags on AmmarServer which seem to be a nice way for cache handshaking ( and work very well with my internal server side caching mechanism ) ..
To profile my server’s behaviour I am using chromium and the very handy Developer Tools that come integrated in it , Especially the Network Timeline feature is great for debugging this sort of things.. RedBot is also a very useful tool! that I use for debugging HTTP handshakes..
Although my implementation isn’t ready yet I am getting some very weird results when I emmit 304 Not Changed responses illustrated in the screenshots bellow ..!
The screenshots are that big due to my dual 1080p screen setup 
I can’t seem to grasp the reason why a 304 response has such a large “Waiting Time” , Is it my Response header that is missing something , is it the whole Keep Alive thing not being handled properly , or is the waiting time supposed to mean something else in the graph..
How is it possible when only 200 byte headers get served that the response time is 4 times worse than when the full files get served from memory ?
I haven’t still figured it out and it is driving me crazy , but I will get to the bottom of this ..
UPDATE
After some tweaking around and with the help of redbot it turns out that the 304 Not Modified header should retransmit all of the original fields transmitted with the first “200 OK” message.. This means all of the E-Tag , Date etc fields.. I was missing out some of them so including them fixed the behaviour..