JDK-8152393 : SQL Server Reporting Services in WebViews shows 401
  • Type: Bug
  • Component: javafx
  • Sub-Component: web
  • Affected Version: 8u60,9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_8
  • CPU: x86
  • Submitted: 2016-03-04
  • Updated: 2016-05-03
  • Resolved: 2016-05-03
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
8u112Fixed 9Fixed
Related Reports
Duplicate :  

Windows Server 2012R2
Windows 8.1
Windows 7

i use WebView  to show SQL Server Reports (SSRS) for my warehouse management system
the SSRS uses HTTP Authentication (fix with Authenticator)

in 2 older System this works like espected
(uses java 1.7_x)

in the current system, we have made an upgrade to 1.8
i can open the Reports/ rendering is correctly
but after a whole time or change the settings ('Platz' / 'Intervall') or click on [View Report] 
an 401 error occurs

i have created an simply FX Browser test class
the problem only occures in Java 1.8:
1.8_60 -> 401
1.8_74 -> 401
1.7_80 -> works

how i can debug / log URL Connections from WebView 

REGRESSION.  Last worked in version 8u74

1.8_60 -> 401
1.8_74 -> 401
1.7_80 -> works

This bug can be reproduced always.

---------- BEGIN SOURCE ----------
i use this test class
SQL Server Reporting Services

public class AmisTest extends Application {
	 * @param args
	public static void main(String[] args) {
		launch(AmisTest.class, args);

	 * @see javafx.application.Application#start(javafx.stage.Stage)
	public void start(Stage primaryStage) throws Exception {
		Authenticator.setDefault(new Authenticator() {
			 * @see java.net.Authenticator#getPasswordAuthentication()
			protected PasswordAuthentication getPasswordAuthentication() {
				return new PasswordAuthentication("<user>", "<pw>".toCharArray());
		final BorderPane root = new BorderPane();

		final WebView webView = new WebView();
		final WebEngine webEngine = webView.getEngine();
		BorderPane.setMargin(webView, new Insets(2, 4, 4, 4));

		final TextField url = new TextField();
		url.setOnAction(new EventHandler<ActionEvent>() {
			public void handle(ActionEvent event) {

		BorderPane.setMargin(url, new Insets(4, 4, 2, 4));

		primaryStage.setScene(new Scene(root));
---------- END SOURCE ----------

Changeset: 684f7b47cc0f Author: mbilla Date: 2016-05-03 22:21 +0530 URL: http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/684f7b47cc0f

Follow on bug created for unit test case: https://bugs.openjdk.java.net/browse/JDK-8155952

I think a follow-on regression test might be good if it isn't difficult to do.

Looks good. And I was able to reproduce the bug without your fix, and then verify that it is fixed with your patch. +1

webrev: http://cr.openjdk.java.net/~mbilla/8152393/webrev.01/

lgtm. Is it possible to write a regression test case?

@Kevin, The url does not load automatically when we run AmisTest. Wed need to press "enter" at url bar when we launch AmisTest. Also when you run AmitTest under vpn, the current issue JDK-8152393 is not reproducible.

The fix looks correct to me, although the test program for this bug (AmisTest) doesn't do anything when I run it -- with or without your fix -- so I can't verify it. I can verify that the test for JDK-8093859 still works with your fix. One minor nit: Can you wrap the comment onto two lines? The line is very long.

webrev: http://cr.openjdk.java.net/~mbilla/8152393/webrev.00/ Testing : I attached two programs 1. AmisTest.java -> This program tests the current issue JDK-8152393 (On clicking refresh icon, page should be loaded successfully and we should not see 401 error on page) 2. Test.java -> This program tests the 8u40 fix https://bugs.openjdk.java.net/browse/JDK-8093859. On running this program, we shoould not see any exception and page should be redirected to login page successfully. Root Cause: In 8u40, fix for JDK-8093859 introduced catch (IOException e) in case of getInputStream() returning exception in receiveResponse method. getInputStream() throws exception when input stream is null. But in few cases, getInputStream() throws HttpRetryException. Currently HttpRetryException is handled in caller function(doRun) of receiveResponse method. But due to introduction of IOException in 8u40 fix, IOException catches even HttpRetryException and HttpRetryException is not thrown to the caller method (doRun). Hence HttpRetryException is not handled properly and subsequent 200 responce messages are not handled. Fix: when getInputStream throws HttpRetryException, we try to rethrow the HttpRetryException to caller (doRun)

This issue is a regression of https://bugs.openjdk.java.net/browse/JDK-8093859 - [WebView] URLLoader throws an exception on 401 HTTP error with no body. I reverted the fix for JDK-8093859 and current issue JDK-8152393 is not reproducible. There are 2 side effects of fix for JDK-8093859: 1. Not able to process 200 after 401 Fix for JDK-8093859 will make sure that receiveResponse() in URLLoader.java does not raise IOException (by Keeping getInputStream() in try/catch block) in below conditions httperrorcode is 401 and errorstream is nulll and input stream is null. and finally didFinishLoading() is executed followed by returning null. Thus avoiding the IOException. But in current issue, we get 200 after receiving 401. Since didFinishLoading() is called, 200 is not processed and hence getting displayed 401 error message. If we avoid calling didFinishLoading(), we end up in a loop and response processing is never completed. 2. Due to incorrect/missing null checks for inputStream(due to fix for JDK-8093859) before creating GZIPInputStream/InflaterInputStream, we are getting null pointer exceptions. There is another issue JDK-8134838 (Gmail stops working if app constructs a default CookieManager) where we are getting NPE due to the fix for JDK-8093859.

Tested with various jdk versions . jdk -7u111, jdk-8, 8u-33 - Issue is not reproducible. 8u-40, 8u-60, 8u-66, 8u-72, 9 - Issue is reproducible when we give delay of ~1 to 2 seconds before click on refresh icon, But If we keep clicking on refresh icon without any delay, then this issue is not reproducible either.

I got below reply from reporter : The report server unable to connet we have an internal error with this vm fixed, the report in now available Now i tried with jdk-7u111-ea-windows-x64 and on refresh, page is loading properly. I tried with 8u66, 9 and able to reproduce this issue. When i refresh, i can see below error message Sys.WebForms.PageRequestManagerServerErrorException: An unknown error occurred while processing the request on the server. The status code returned from the server was: 401

I tried to reproduce this issue in 8u33-b04, 8u40, 8u60 and 9 from the code given in JDK-8153380. But im not able to reproduce the 401 issue as i was getting only blank screen. I tried below url in chrome browser and was gettig Services Error. with username/passwd as OracleLogin / Oracle&9i5 I can see from wireshark logs (for Chromium case) that 401 message is being received as reply to above URL. So i guess, receiving 401 error is not specific to FX code as im able to reproduce in chrome browser too. I attached the wireshark snapshot as attachment (chromium.pcappng). In short i can see below 3 GET and 3 responses: GET /ReportServer/Pages/ReportViewer.aspx?%2fBerichtsprojekt1%2ftestReport&rs:Command=Render HTTP/1.1 HTTP/1.1 401 Unauthorized GET /ReportServer/Pages/ReportViewer.aspx?%2fBerichtsprojekt1%2ftestReport&rs:Command=Render HTTP/1.1 , NTLMSSP_NEGOTIATE HTTP/1.1 401 Unauthorized GET /ReportServer/Pages/ReportViewer.aspx?%2fBerichtsprojekt1%2ftestReport&rs:Command=Render HTTP/1.1 , NTLMSSP_AUTH, User: \OracleLogin HTTP/1.1 500 Server Error

Please see the bug JDK-8153380 for additional information (like url, username, password) on how to reproduce.