OK I just put out a new release here that should a number of bug fixes identified over the past year and a half. Hope this helps, belatedly. Let me know what you think.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I don't have reason to expect that performance changed. The changes were almost all correctness fixes. For example maybe the ETag change lets the container properly respond to new requests for a cached entity with 304 Not Modified? that's the only sort of performance effect I can think of.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
does that mean the browser gets a 304 so it is able to cache properly? if so that would match what i'm seeing, as the second hit to any page is pretty much instantaneous.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If it enables caching, it is through some indirect consequence of the fixes - the container or browser is now willing to use the mechanism as intended. The ETag change itself would actually prevent some incorrect caching, but may have indirectly enabled something else to work.
I would be curious to see the request/response that seems faster. Can you capture with Firefox + LiveHTTPHeaders to see what happened? Would like to see the headers and response code.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
there's only one difference between the the response headers. the first time i go to the page there is the following line..
Cache-Control private
if i refresh the page the response is missing this line and the page loads quicker. the actual response code is the same (HTTP/1.1 200 OK). maybe it lets resin's cache work properly...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think you are thinking of no-cache? A 'private' response may be cached by the browser but not intermediate proxies. In any event the filter itself does not cache or pay attention to any directive except 'no-transform' (which cancels compression).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK I just put out a new release here that should a number of bug fixes identified over the past year and a half. Hope this helps, belatedly. Let me know what you think.
thanks for the update...
it seems snappier - is the way it interacts with the caching mechs improved?
I don't have reason to expect that performance changed. The changes were almost all correctness fixes. For example maybe the ETag change lets the container properly respond to new requests for a cached entity with 304 Not Modified? that's the only sort of performance effect I can think of.
does that mean the browser gets a 304 so it is able to cache properly? if so that would match what i'm seeing, as the second hit to any page is pretty much instantaneous.
If it enables caching, it is through some indirect consequence of the fixes - the container or browser is now willing to use the mechanism as intended. The ETag change itself would actually prevent some incorrect caching, but may have indirectly enabled something else to work.
I would be curious to see the request/response that seems faster. Can you capture with Firefox + LiveHTTPHeaders to see what happened? Would like to see the headers and response code.
there's only one difference between the the response headers. the first time i go to the page there is the following line..
Cache-Control private
if i refresh the page the response is missing this line and the page loads quicker. the actual response code is the same (HTTP/1.1 200 OK). maybe it lets resin's cache work properly...
Any response with Cache-Control private should not be cached by the browser or any other caching mechanism. So the 200 http status is the right one!
I think you are thinking of no-cache? A 'private' response may be cached by the browser but not intermediate proxies. In any event the filter itself does not cache or pay attention to any directive except 'no-transform' (which cancels compression).