I meant use the ContentType of entity from ClientRequestContext instead of Accept.

For the accept type and response content type dismatch, this is something server side should handle and http 406 should be returned for this case.
If accept type is application/json with response content type is application/xml is replied by other server, and user still wants to consume
this application/xml type result and cache can still support this.  WDYT ?
 

On 10/22/2018 02:38 PM, Petr Jurak wrote:
Yep, this will and actually this was the original idea to use Accept instead of Content-Type. But I had some doubts if this is good solution.

Let me sum it up what I want to do:
Use Accept if present, if not use Content-Type. Charset will not be taken into account.

Note: as an example, Content-Type is application/xml and Accept is application/json, so it will be stored with application/json, but the real content is XML. This is my main concern.

Cheers,
Petr


On Mon, Oct 22, 2018 at 4:53 AM Jim Ma <ema@redhat.com> wrote:
Can we only use the request uri + method + request mediaType as the cache key ?
Will this resolve these two issues ?

Thanks,
Jim

On 10/18/2018 03:27 PM, Petr Jurak wrote:
Hi,

I was looking into RESTEASY-2038 [1]. I'm not sure how to handle this correctly so I need to know your opinion.

In the org.jboss.resteasy.client.jaxrs.cache.CacheInterceptor there is a method for storing response in the cache containing this part. 

String contentType = (String) response.getHeaderString(HttpHeaders.CONTENT_TYPE);
byte[] cached = ReadFromStream.readFromStream(1024, response.getEntityStream());
MediaType mediaType = MediaType.valueOf(contentType);
final BrowserCache.Entry entry = cache.put(request.getUri().toString(), mediaType,
        response.getHeaders(), cached, expires, etag, lastModified);

Later, once the same GET method is executed, the interceptor checks if there is an entry in the cache for the given Accept type.

BrowserCache.Entry entry = getEntry(request);

In the getEntry method it checks for the type

entry = cache.get(uri, accept);
if (entry != null) return entry;
if (MediaTypeHelper.isTextLike(accept))
{
      entry = cache.get(uri, accept.withCharset("UTF-8"));
      if (entry != null) return entry;
}

Let's assume that resource returns XML data with Content-Type: application/xml;charset=UTF-8
and the client sends Accept: application/xml
So the very first request adds into the cache entry for application/xml;charset=UTF-8 because it is taken from Content-Type header.

Subsequent request gets the cached value (expecting that entry is not expired), although it cannot find it under application/xml, it is found under application/xml;charset=UTF-8 because of this:

cache.get(uri, accept.withCharset("UTF-8"));

The problem is if decide to change the code to use Accept instead of current Content-Type, we can't be sure if there is Accept header in the request and we're not sure about response encoding.

Also the statement in Jira regarding content type mismatch: like Accept is application/json, but resource returns application/xml and to store it under application/json instead of application/xml is IMHO wrong (coding issue). I believe that it should be stored per actual content type.

Your thoughts?

Thanks!

Cheers,
Petr








_______________________________________________
resteasy-dev mailing list
resteasy-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/resteasy-dev




--

PETR JURAK

SENIOR SOFTWARE ENGINEER

Red Hat