Issue #11536 - ServletContext.getResourceAsStream(String) must use URLConnection
#11537
Conversation
joakime
added
Bug
| // Per servlet rules, we have to use URLConnection to return this stream. | ||
| URLConnection urlConnection = url.openConnection(); | ||
| urlConnection.setUseCaches(false); | ||
| return urlConnection.getInputStream(); |
There was a problem hiding this comment.
@janbartel is not at her computer, but has pointed out that the javadoc does not require URLConnection to be used? I really think we should avoid this as once URLs are used, then the URL cache mechanism is engaged and we loose control over jar caching.
What makes you think we should use URLConnection?
There was a problem hiding this comment.
See the javadoc on ServletContext.getResourceAsStream(String)
- Servlet 6 - https://github.com/jakartaee/servlet/blob/6.0.0/api/src/main/java/jakarta/servlet/ServletContext.java#L275-L277
- Servlet 5 - https://github.com/jakartaee/servlet/blob/5.0.0/api/src/main/java/jakarta/servlet/ServletContext.java#L283-L285
- Servlet 4 - https://github.com/jakartaee/servlet/blob/4.0.4/api/src/main/java/javax/servlet/ServletContext.java#L285-L287
Which all say ...
* <p> * The servlet container must implement the URL handlers and <code>URLConnection</code> objects necessary to access * the resource.
Also note that url caching is disabled in the impl on this PR.
There was a problem hiding this comment.
@joakime I think you are reading that the wrong way. It says that if a URL handler is necessary to access a resource, then the server must implement it. But nothing says that the server must use a URL to access resource that a URL handler is not necessary for.
We really do not want to do this and re-open the whole can of worms that is the caching done by the URL API. The big selling point of switching to PathResource was precisely that we could control the mounting and unmounting of the zipfs used to access jar resources. If we start using the URL API again, then we lose that control over memory again.
Specifically, for the issue associated with this... using URL is more likely to lock a file in the filesystem than not using it.
There was a problem hiding this comment.
This is not necessary for other issue, just something I noticed while troubleshooting it.
Moved this PR (and issue) to 12.0.9, as it needs further analysis.
There was a problem hiding this comment.
@joakime yeah, let's have a bit more of a think about this one. I'm not convinced that the spec is/should dictate that the InputStream must be obtained from a URLConnection - the words are bit open to interpretation, and the contract of the method signature is purely InputStream. Not sure I really want to reopen the whole URLConnection cache can-of-worms again - didn't taste great the last time around ;)
Making Implementations of
ServletContext.getResourceAsStream(String)useURLConnectionproperly (per spec) in ee10/ee9 codebases.Fixes #11536