Bug ID: JDK-8024810 java.net.HttpURLConnection.getResponseCode return IOException instead of code

Type: Bug
Component: core-libs
Sub-Component: java.net
Affected Version: 8

Priority: P3
Status: Resolved
Resolution: Cannot Reproduce
OS: linux_ubuntu

Submitted: 2013-08-28
Updated: 2013-10-15
Resolved: 2013-10-15

FULL PRODUCT VERSION :
java version "1.8.0-ea"
Java(TM) SE Runtime Environment (build 1.8.0-ea-b100)
Java HotSpot(TM) 64-Bit Server VM (build 25.0-b42, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
Linux walec51-linux 3.8.0-29-generic #42-Ubuntu SMP Tue Aug 13 19:40:39 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

A DESCRIPTION OF THE PROBLEM :
Found it while developing an app that uses the Hessian protocol. java.net.HttpURLConnection.getResponseCode throws IOException instead of returning HTTP codes 4xx and 5xxx

This makes exception handling useless. If the client app user type the wrong username/password I can only give him a Fatal connection error message because there is no way to get the response code.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Try to java.net.HttpURLConnection.getResponseCode from an URL that returns a 4xx or 5xx code.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The HTTP code.
ACTUAL -
IOException.

ERROR MESSAGES/STACK TRACES THAT OCCUR :
Same thing happens on error codes 401 or 403 for example:

Caused by: java.io.IOException: Server returned HTTP response code: 500 for URL: http://localhost:8001/ProdokoSecurityService
at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1781)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1382)
at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:480)
at com.caucho.hessian.client.HessianURLConnection.sendRequest(HessianURLConnection.java:112)
... 17 more

REPRODUCIBILITY :
This bug can be reproduced often.

There is limited information in the description to proceed with this issue, but I have demonstrated, below, that the HTTP client implementation does return error codes, as applicable. Most likely there is something else in the submitters environment, "bad" server response, or network issue that is causing the IOException. ---- import java.net.*; import com.sun.net.httpserver.*; import java.io.IOException; public class Test { public static void main(String[] args) throws IOException { HttpServer httpServer = startHttpServer(); try { final int port = httpServer.getAddress().getPort(); for (int i : TestHandler.respCodes) System.out.print(get(port) + " "); System.out.println(""); } finally { httpServer.stop(0); } } static int get(int port) throws IOException { URL url = new URL("http://localhost:" + port + "/test/"); HttpURLConnection uc = (HttpURLConnection) url.openConnection(); return uc.getResponseCode(); } static HttpServer startHttpServer() throws IOException { HttpServer httpServer = HttpServer.create(new InetSocketAddress(0), 0); HttpContext ctx = httpServer.createContext("/test/", new TestHandler()); httpServer.start(); return httpServer; } static class TestHandler implements HttpHandler { static final int[] respCodes = { 400, 401, 402, 403, 404, 405, 406, 407, 408, 409, 410, 411, 412, 413, 414, 415, 416, 417, 500, 501, 502, 503, 504, 505 }; static volatile int count; public void handle(HttpExchange t) throws IOException { t.sendResponseHeaders(respCodes[count++], -1); t.close(); } } } ---- $ : /java/re/jdk/6u45/latest/binaries/solaris-sparc/bin/java -version java version "1.6.0_45" Java(TM) SE Runtime Environment (build 1.6.0_45-b06) Java HotSpot(TM) Server VM (build 20.45-b01, mixed mode) $ : /java/re/jdk/6u45/latest/binaries/solaris-sparc/bin/java Test 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 500 501 502 503 504 505 $ : /java/re/jdk/7u40/latest/binaries/solaris-sparc/bin/java -version java version "1.7.0_40" Java(TM) SE Runtime Environment (build 1.7.0_40-b43) Java HotSpot(TM) Server VM (build 24.0-b56, mixed mode) $ : /java/re/jdk/7u40/latest/binaries/solaris-sparc/bin/java Test 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 500 501 502 503 504 505 $ : /java/re/jdk/7u6/latest/binaries/solaris-sparc/bin/java -version java version "1.7.0_06" Java(TM) SE Runtime Environment (build 1.7.0_06-b24) Java HotSpot(TM) Server VM (build 23.2-b09, mixed mode) $ : /java/re/jdk/7u6/latest/binaries/solaris-sparc/bin/java Test 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 500 501 502 503 504 505 $ : /java/re/jdk/8/latest/binaries/solaris-sparcv9/bin/java -version java version "1.8.0-ea" Java(TM) SE Runtime Environment (build 1.8.0-ea-b111) Java HotSpot(TM) 64-Bit Server VM (build 25.0-b53, mixed mode) $ : /java/re/jdk/8/latest/binaries/solaris-sparcv9/bin/java Test 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 500 501 502 503 504 505

15-10-2013

Is this a change in behavior from a previous release? Or is this bug simply complaining about expected behavior?

27-09-2013