(note: replaces https://github.com/FasterXML/jackson-databind/issues/3520)

It looks like JDK's HttpURLConnection has unfortunate handling of some error cases, leading to leakage of not-fully-closed HTTP connections under some error conditions. See https://github.com/FasterXML/jackson-databind/issues/3455 for details.

It seems like we might be able to handle some of those cases if we could do something like:

URLConnection connection = new URL(url).openConnection();
try (InputStream stream = connection.getInputStream()) {
  // parse JSON
} finally {
  // java.net.HttpURLConnection.HttpURLConnection
  if (connection instanceof HttpURLConnection) {
    ((HttpURLConnection) connection).disconnect();
  }
}

(as suggested by @fxha -- thanks!)

But due to separation of concerns, this cannot (or should not) be done in databind. Instead we could wrap URL-backed InputStream in these cases, delegated all calls except for close(): and in close() we would do disconnect.

Comment From: cowtowncoder

Is #1461 same as this one? Seems related at least.

Comment From: pjfanning

@cowtowncoder can I make a left field suggestion? Can we deprecate the API methods that take URL inputs and remove them from 3.x. Jackson libs have enough to worry about and having users ask us to support HTTP connections and do connection pooling - that says to me that we are offering a convenience feature that we don't really need. Let users manage their own URL lookups and get InputStreams that they pass to Jackson. They can worry about all the URL stuff like error handling, connection pooling and validating the URLs are not dangerous.

Comment From: cowtowncoder

@pjfanning I wish this idea came out earlier (my bad) -- but timing is pretty bad for removal. I do like the idea itself, just worried it's very late in the game.

But I could see what the consensus might be.

/cc @sdeleuze how is the Spring release train going? I'll release 3.0.0-rc8 today (next) but would want to know if Spring might be using/exposing URL taking methods from JsonFactory / ObjectMapper.

Comment From: pjfanning

I suspect the APIs are not commonly used. I think most users would appreciate that it is dangerous territory to try pulling inputs from an external URL. You need to manage certs, handle network issues and just generally, there are a lot of risks. It might be convenient for a POC but beyond that, I hope most users are sensible enough to avoid using the URL inputs.

If we choose not to remove the methods, we could go down the route of updating the Javadoc to discourage use but then we have to contend with how few people read the Javadocs - especially if they are just upgrading the jar versions.

Comment From: sdeleuze

@cowtowncoder I see no such usage on Spring Framework side, but I will ask to the wider team to comment here if other projects have such usage.

Comment From: cowtowncoder

Superceded by #1462, closing.