Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ensure HTTP caching plays well with Etag based caching #11

Closed
sitemesh opened this issue Sep 4, 2009 · 2 comments
Closed

Ensure HTTP caching plays well with Etag based caching #11

sitemesh opened this issue Sep 4, 2009 · 2 comments

Comments

@sitemesh
Copy link
Collaborator

sitemesh commented Sep 4, 2009

Dan Bodart is the man to speak about this.

http://code.google.com/p/webfabric/wiki/EtagSupport

@danielbodart
Copy link

Addressing the ETag issue might be a thorny issue. Let me explain a little more about ETags:

There are two types, Strong and Weak.

A strong ETag must change if a single byte in the response entity changes, it works at the syntactic level. It must be issued by the origin server. Any change to the content including content-encoding must create a unique ETag. Transfer encoding does not need to change the ETag as it's hop by hop not end to end.

A weak ETag must change if there is a significant (from the client's perspective) symantic change to the resource (notice i didn't say response entity). Ie if the change is minor and doesn't change the meaning then a weak etag doesn't need to change. So you could say the png and gif logos might have the same weak etags and if the urls where the same a cache could return either if the client accepted the media type.

So this relates to the Last Modified bug you just fixed with dynamic content. Etags where added specifically for dynamic content, as creating a last modified date can be a big challenge for large composite pages and in someways the last modified date should be when the response is sent.

Anyway the way I see it is you could just ignore the issue and say that as you are the origin server and as the request is getting decorated every time then actually the ETag is valid. I.e. if you repeat the request you get the same answer.

The issue for me is once you start combining the ability to change the decorator in some out of bounds mechanism (xml config or editing etc), now for a weak etag you can probably just say it's fine (though again if the change was massive you have the same problem). A strong one it's definitely an issue.

Now I see one other way of fixing this (other than the webfabric way), make the decorators return strong etags and if all responses contain etags concatinate the etags to make a decorated etag much like what you did with the last modified. And decompose the etag on the way back down to the servlet.

Etag: "decorator: adf6576t7sdf ( decoator: fds67fs5d8 ( content: 328768rf6we897 ) )"

Or something like that.

In summary:

* Ignore it
* Decorate the ETag
* MD5 the content

@codeconsole
Copy link
Member

Stale issue. Please re-open if still needs exploring.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants