Hi Stokes, Thanks for launching this thread. Your description of the Restlet behavior is accurate and your solution is valid. You don't have to worry about HTTP headers being streamed as the Restlet API fully decouples the request reading, handling and response writing tasks.
I would be interested to know which caching service you rely on, because if it supports HTTP 1.1 it should definitely support the Vary header. Actually, this header is precisely here to indicate to those services which request headers can influence the returned representation for a given URI: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.44 Now, there is an easier way for you to workaround this caching issue, because you don't rely on content negotiation. On your resource, call setNegotiateContent(false). Best regards, Jerome > -----Message d'origine----- > De : news [mailto:[EMAIL PROTECTED] De la part de Stokes > Envoyé : mercredi 28 mars 2007 19:09 > À : [email protected] > Objet : Vary headers, content negotiation, and HTTP caching > > I want my REST service's GET requests to be cached by a > forward caching service. > By default, my Restlet responses are not getting cached. > The service we use says: > "Our system does not support Vary headers with any value other than > Accept-Encoding. This is because this setting would imply > that the > content could be different although the URL itself > remains constant." > > I'm not familiar with the details of content negotiation (I'd > love to be > enlightened if anyone can post a summary), but I gather (a) > it's a common > RESTful practice, and (b) I don't have much use for it since > my Resources are > only represented as XML with the same language and character set. > > By default my Restlet response headers have "Vary: > Accept-Charset,Accept-Encoding,Accept-Language,Accept". To > be cachable by our > service, I have to remove most of those. It looks like those > 'Dimensions' are > being added by Resource.handleGet(), and there's no way to > override what gets > added. I have custom Resource implementations that all > extend the same parent > class, so in that parent I've overridden handleGet() as follows: > public void handleGet() { > super.handleGet(); > Set<Dimension> dims = getResponse().getDimensions(); > dims.remove(Dimension.CHARACTER_SET); > dims.remove(Dimension.LANGUAGE); > dims.remove(Dimension.MEDIA_TYPE); > } > Is this okay? It seems to work fine, but I wasn't sure if > there was ever a > point-of-no-return regarding Responses, e.g. if bytes have > already been streamed > back and headers can no longer be changed. > > I'm posting all this: > (1) To start a discussion that may benefit others who may > run into this > problem with HTTP caching services, > (2) To find out what features I'm missing by removing these > Dimensions, > (3) In case my plight influences Jerome and Thierry (who > are great at > responding to user feedback, btw) to add something like > "protected void > setGetResponseDimentions()", if it's warranted... or in some > way to override the > Resources behavior without doing my > call-the-super-method-and-then-undo-part-of-what-it-did override. > > Stokes.
