Jerome Louvel wrote:
Note that currently the "Cache-Control" header is not supported. We only
support the "Last-Modified" and "If-Modified-Since" headers. See the list of
unsupported HTTP headers here:
http://restlet.tigris.org/issues/show_bug.cgi?id=282

Cache-Control has nothing to do with Last-Modified. One is part of the Validation model, the other is part of the Expiration Model...


           | HTTP/1.0          | HTTP/1.1
-------------------------------------------------
Expiration | Expires           | Cache-Control
-------------------------------------------------
Validation | Last-Modified /   | Etag /
           | If-Modified-Since | If-None-Match
-------------------------------------------------

Expiration tells caches when their representations expire in the cache. This tells the cache when the representation is stale. Validation tells the cache if a stale object is or is not still valid.

The point being, even though Restlet doesn't support Cache-Control, it doesn't really matter too much with regards to the server side of Restlet. A developer can add the Cache-Control header to the outbound response and that's all that is really needed support-wise from RESTlet.

Restlet has support for Last-Modified / If-Modified-Since, and Etag / If-None-Match headers. This support is all that is needed in order to correctly validate a stale representation and send a 304 Not Modified response.

If the RESTlet engine was ever turned into a caching proxy, then additional support for Cache-Control will be needed.

I don't believe Vladimir's issue has anything to do with lack of support for Cache-Control. It looks to me as if somewhere (either his code or in the RESTlet code), the Last-Modified and/or Etag values are not being computed or validated correctly.

Perhaps the bug is because Vladimir is only sending an ETag out from the server to the client? Perhaps he should be sending both an ETag and a Last-Modified header. I.e. Perhaps the bug is in Restlet's handling of If-None-Match code?

It looks like Vladimir is trying to use HTTP/1.1 headers only, which makes me wonder if that's where the bug is at.

Adam

Reply via email to