304 not modified from Server doesn't contain Cache-Control header

[GDownes]

Making a request to an endpoint with the HttpCacheControlPolicy attribute returns a Cache-Control header as expected.

Making a second request with the responses returned ETag returns a 304 Not Modified response as expected, but the response doesn't contain the same cache control header returned with the first request.

In #117 the ability to update the client side cache using the returned cache-control header was added.

I would like the 304 Not Modified server response to contain the same Cache-Control header as the 200 response to aid in refreshing the stale client side cache.

[aliostad]

OK, sorry for a long delay.
I just had some time to fix this.

[aliostad]

OK, this will never work. We send back the 304 before controller is called (pretty much the whole point) and even before HttpRoutingDispatcher is invoked, since this is at the time of delegating handlers. This results in route data being null. So if we are using attribute based approach, this won't work.

I am afraid there is no easy way of making this work so can't be done.

[Reyhn3]

This bug is causing problems right now, see #142.
According to RFC 7232, section 4.1, a 304 must always return a cache-control header:

The server generating a 304 response MUST generate any of the
following header fields that would have been sent in a 200 (OK)
response to the same request: Cache-Control, Content-Location, Date,
ETag, Expires, and Vary.

https://tools.ietf.org/html/rfc7232#section-4.1