Return ETag on 304 as well.

[Dragomir-Ivanov]

Reading something about ETags, I found this: http://www.bendeutsch.de/blog/The-difference-between-strong-and-weak-ETags

It seems that WebApp/Browser can supply multiple Etags on GET request for cached resources, so server must pick the right one, thus needs to return latest ETag on 304.

[Dragomir-Ivanov]

I guess further down the line, we will need to add support for multiple ETags supplied to HEAD/GET. But this issue can wait though. @smyrman Can you add Enhancement label.

[rs]

The thing is that sub-resource etags aren't current's one and an etag is associated with a specific path+query-string, so it should not be used to edit another resource.

[smyrman]

The link you posted is extremely useful @Dragomir-Ivanov.

The thing is that sub-resource etags aren't current's one and an etag is associated with a specific path+query-string, so it should not be used to edit another resource.

As I understand it from the link, it's not about sending multiple sub-resource E-tags, but about sending an E-tag for multiple versions of the same resource (path+query-string).

So a client (or browser) could theoretically cache up several versions of resource /a/1, and then ask the server:

• Client: Does the version you got of /a/1 match E-Tag v1,v3 or v2? If not, please return it to me.
• Server: 304 NotModified, and btw I got E-tag v3 over here.

[smyrman]

Btw, this is defiantly in the enchantment category. The main goal of supporting it would be out of correctness and browser compatibility - if this is something that a lot of browsers do.

[rs]

Oh yeah ok, got it. Yes absolutely, we should create a ticket for that.