[
https://issues.apache.org/jira/browse/HTTPCLIENT-1225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eli Bishop updated HTTPCLIENT-1225:
-----------------------------------
Description:
The fix for HTTPCLIENT-1202 removed null checking on the resource field of
HttpCacheEntry. Unfortunately, CacheValidityPolicy expects the resource to be
non-null, so you can get an NPE on the next cache hit on that entry:
java.lang.NullPointerException
at
org.apache.http.impl.client.cache.CacheValidityPolicy.contentLengthHeaderMatchesActualLength(CacheValidityPolicy.java:219)
at
org.apache.http.impl.client.cache.CachedResponseSuitabilityChecker.canCachedResponseBeUsed(CachedResponseSuitabilityChecker.java:139)
at
org.apache.http.impl.client.cache.CachingHttpClient.handleCacheHit(CachingHttpClient.java:446)
at
org.apache.http.impl.client.cache.CachingHttpClient.execute(CachingHttpClient.java:437)
at
org.apache.http.impl.client.cache.CachingHttpClient.execute(CachingHttpClient.java:353)
As far as I can tell, the resource will only be null if the response status is
one that can never have a response body: 204, 205, or 304. There's other
special-case logic for 304 which seems to avoid hitting this code path; but if
a server returns a 204 or 205 with a Cache-Control header (unusual, but I saw
it happen), you have a problem.
was:
The fix for HTTPCLIENT-1202 removed null checking on the resource field of
HttpCacheEntry. Unfortunately, CacheValidityPolicy expects the resource to be
non-null, so you can get an NPE on the next cache hit on that entry:
{code}
java.lang.NullPointerException
at
org.apache.http.impl.client.cache.CacheValidityPolicy.contentLengthHeaderMatchesActualLength(CacheValidityPolicy.java:219)
at
org.apache.http.impl.client.cache.CachedResponseSuitabilityChecker.canCachedResponseBeUsed(CachedResponseSuitabilityChecker.java:139)
at
org.apache.http.impl.client.cache.CachingHttpClient.handleCacheHit(CachingHttpClient.java:446)
at
org.apache.http.impl.client.cache.CachingHttpClient.execute(CachingHttpClient.java:437)
at
org.apache.http.impl.client.cache.CachingHttpClient.execute(CachingHttpClient.java:353)
{code}
As far as I can tell, the resource will only be null if the response status is
one that can never have a response body: 204, 205, or 304. There's other
special-case logic for 304 which seems to avoid hitting this code path; but if
a server returns a 204 or 205 with a Cache-Control header (unusual, but I saw
it happen), you have a problem.
> A cacheable no-body response causes a NPE when that cache entry is hit
> ----------------------------------------------------------------------
>
> Key: HTTPCLIENT-1225
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1225
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: Cache
> Affects Versions: 4.2.1
> Reporter: Eli Bishop
>
> The fix for HTTPCLIENT-1202 removed null checking on the resource field of
> HttpCacheEntry. Unfortunately, CacheValidityPolicy expects the resource to be
> non-null, so you can get an NPE on the next cache hit on that entry:
> java.lang.NullPointerException
> at
> org.apache.http.impl.client.cache.CacheValidityPolicy.contentLengthHeaderMatchesActualLength(CacheValidityPolicy.java:219)
> at
> org.apache.http.impl.client.cache.CachedResponseSuitabilityChecker.canCachedResponseBeUsed(CachedResponseSuitabilityChecker.java:139)
> at
> org.apache.http.impl.client.cache.CachingHttpClient.handleCacheHit(CachingHttpClient.java:446)
> at
> org.apache.http.impl.client.cache.CachingHttpClient.execute(CachingHttpClient.java:437)
> at
> org.apache.http.impl.client.cache.CachingHttpClient.execute(CachingHttpClient.java:353)
> As far as I can tell, the resource will only be null if the response status
> is one that can never have a response body: 204, 205, or 304. There's other
> special-case logic for 304 which seems to avoid hitting this code path; but
> if a server returns a 204 or 205 with a Cache-Control header (unusual, but I
> saw it happen), you have a problem.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
