You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by "Oleg Kalnichevski (Jira)" <ji...@apache.org> on 2019/11/06 17:50:00 UTC
[jira] [Resolved] (HTTPCLIENT-2022)
HttpCacheEntrySerializationException Message Unused
[ https://issues.apache.org/jira/browse/HTTPCLIENT-2022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Oleg Kalnichevski resolved HTTPCLIENT-2022.
-------------------------------------------
Fix Version/s: 4.5.11
Resolution: Fixed
Merged to 4.5.x branch.
Oleg
> HttpCacheEntrySerializationException Message Unused
> ---------------------------------------------------
>
> Key: HTTPCLIENT-2022
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2022
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpCache
> Affects Versions: 4.5.10
> Reporter: Olof Larsson
> Priority: Minor
> Fix For: 4.5.11
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> *In Short*
> The HttpCacheEntrySerializationException message is unused in one of the class constructors. This looks like an easily corrected coding mistake.
> *Further Explanation*
> DefaultHttpCacheEntrySerializer has a code section looking like this:
> {code:java}
> @Override
> protected Class<?> resolveClass(final ObjectStreamClass desc) throws IOException, ClassNotFoundException {
> if (isProhibited(desc)) {
> throw new HttpCacheEntrySerializationException(String.format(
> "Class %s is not allowed for deserialization", desc.getName()));
> }
> return super.resolveClass(desc);
> }
> {code}
> The constructor used looks like this:
> {code:java}
> public HttpCacheEntrySerializationException(final String message) {
> super();
> }
> {code}
> This means the useful error message created using string format will actually never be displayed in an error stack trace.
> *User Case*
> When trying to upgrade from 4.5.8 to 4.5.10 one of my applications stopped working.
> I have a custom implementation of persistent disk cache storage. It makes use of the DefaultHttpCacheEntrySerializer.
> The stack trace did not tell me what was wrong (because the informative string is not passed along in the constructor)
> {noformat}
> ...
> Caused by: java.lang.RuntimeException: org.apache.http.client.cache.HttpCacheEntrySerializationException
> at com.looklet.net.httpclientwrapper.executor.RequestExecutorImpl.executeToResponse(RequestExecutorImpl.java:46)
> at com.looklet.net.httpclientwrapper.executor.RequestExecutorImpl.execute(RequestExecutorImpl.java:66)
> ... 63 more
> Caused by: org.apache.http.client.cache.HttpCacheEntrySerializationException
> at org.apache.http.impl.client.cache.DefaultHttpCacheEntrySerializer$RestrictedObjectInputStream.resolveClass(DefaultHttpCacheEntrySerializer.java:107)
> at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1868)
> at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1751)
> ...{noformat}
> I had to use a debugger to figure out that the message was:
> "Class [C is not allowed for deserialization"
> Apparently this security patch forbids char arrays? ([https://reverseengineering.stackexchange.com/questions/17429/b-symbol-in-java-bytecode])
> On a side note maybe the whitelist could be expanded to allow all kinds of primitives and arrays of primitives?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org