[resteasy-dev] RESTEASY-2038

[Jim Ma]

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 at redhat.com 
> <mailto:ema at 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
>>
>>
>>
>>
>>
>>
>>     [1] https://issues.jboss.org/browse/RESTEASY-2038
>>
>>
>>
>>     _______________________________________________
>>     resteasy-dev mailing list
>>     resteasy-dev at lists.jboss.org <mailto:resteasy-dev at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/resteasy-dev
>
>
>
>
> -- 
>
> PETR JURAK
>
> SENIOR SOFTWARE ENGINEER
>
> Red Hat
>
> <https://www.redhat.com/>
>
> <https://red.ht/sig> 	
> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/resteasy-dev/attachments/20181022/94169389/attachment-0001.html