Menu
▾
▴
#314 Error: unable to read from stream
DTD check fails on HTTPS with BasicAuth:
I can't use a remote configuration when it is located on a web server with SSL and BasicAuth enabled. Ends up with "Checkstyle-Plugin: unable to read from stream".
Putting the same configuration file in a usual HTTP or local folder works.
Reproduced on Eclipse 3.5 and 3.6, Checkstyle Plugin 5.2.0
Using DTD as decribed at http://checkstyle.sourceforge.net/config.html#XML%20Details
Ends up in
java.io.IOException: Server returned HTTP response code: 503 for URL: http://www.w3.org/TR/html4/loose.dtd
This file is available - for sure!
My guess: The configuration check uses the same authentication credentials for usual HTTP access as configured for the checkstyle configuration file. I don't think, that HTTPS is causing the problem, because the protocol should be handled correctly by HttpUrlConnection in the usual way.
Doesn't seem to be the same but could be related to bug 1820697:
https://sourceforge.net/tracker/index.php?func=detail&aid=1820697&group_id=80344&atid=559494
Complete stack trace:
net.sf.eclipsecs.core.util.CheckstylePluginException: unable to read from stream
at net.sf.eclipsecs.core.util.CheckstylePluginException.rethrow(CheckstylePluginException.java:66)
at net.sf.eclipsecs.core.util.CheckstylePluginException.rethrow(CheckstylePluginException.java:77)
at net.sf.eclipsecs.core.config.CheckConfigurationTester.getUnresolvedProperties(CheckConfigurationTester.java:105)
at net.sf.eclipsecs.ui.config.CheckConfigurationPropertiesDialog.okPressed(CheckConfigurationPropertiesDialog.java:313)
at org.eclipse.jface.dialogs.Dialog.buttonPressed(Dialog.java:472)
at org.eclipse.jface.dialogs.Dialog$2.widgetSelected(Dialog.java:624)
at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:234)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1053)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4066)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3657)
at org.eclipse.jface.window.Window.runEventLoop(Window.java:825)
at org.eclipse.jface.window.Window.open(Window.java:801)
at net.sf.eclipsecs.ui.config.CheckConfigurationWorkingSetEditor.addCheckConfig(CheckConfigurationWorkingSetEditor.java:465)
at net.sf.eclipsecs.ui.config.CheckConfigurationWorkingSetEditor.access$1(CheckConfigurationWorkingSetEditor.java:461)
at net.sf.eclipsecs.ui.config.CheckConfigurationWorkingSetEditor$PageController.widgetSelected(CheckConfigurationWorkingSetEditor.java:383)
at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:234)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1053)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4066)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3657)
at org.eclipse.jface.window.Window.runEventLoop(Window.java:825)
at org.eclipse.jface.window.Window.open(Window.java:801)
at org.eclipse.ui.internal.dialogs.WorkbenchPreferenceDialog.open(WorkbenchPreferenceDialog.java:211)
at org.eclipse.ui.internal.OpenPreferencesAction.run(OpenPreferencesAction.java:65)
at org.eclipse.jface.action.Action.runWithEvent(Action.java:498)
at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:584)
at org.eclipse.jface.action.ActionContributionItem.access$2(ActionContributionItem.java:501)
at org.eclipse.jface.action.ActionContributionItem$5.handleEvent(ActionContributionItem.java:411)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1053)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4066)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3657)
at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2640)
at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2604)
at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2438)
at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:671)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:664)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:115)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:369)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:619)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:574)
at org.eclipse.equinox.launcher.Main.run(Main.java:1407)
Caused by: com.puppycrawl.tools.checkstyle.api.CheckstyleException: unable to read from stream
at com.puppycrawl.tools.checkstyle.ConfigurationLoader.loadConfiguration(ConfigurationLoader.java:400)
at net.sf.eclipsecs.core.config.CheckConfigurationTester.getUnresolvedProperties(CheckConfigurationTester.java:102)
... 50 more
Caused by: java.io.IOException: Server returned HTTP response code: 503 for URL: http://www.w3.org/TR/html4/loose.dtd
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.setupCurrentEntity(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.startEntity(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.startDTDEntity(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLDTDScannerImpl.setInputSource(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$DTDDriver.dispatch(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$DTDDriver.next(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$PrologDriver.next(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source)
at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(Unknown Source)
at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(Unknown Source)
at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
at com.puppycrawl.tools.checkstyle.api.AbstractLoader.parseInputSource(AbstractLoader.java:98)
at com.puppycrawl.tools.checkstyle.ConfigurationLoader.parseInputSource(ConfigurationLoader.java:272)
at com.puppycrawl.tools.checkstyle.ConfigurationLoader.loadConfiguration(ConfigurationLoader.java:383)
... 51 more
Hmm, I am at loss on why the XML parser (see root exception at the end of your trace) would try to resolve the html4 DTD from the internet.
Need to hunt for a possibility to stop the parser from doing this, but even if I find some - the parser instance is created deep inside Checkstyle core bowels (at com.puppycrawl.tools.checkstyle.api.AbstractLoader.parseInputSource(AbstractLoader.java:98) - so there is probably no way I can influence that from the plugin side...
Hah! see here for an explanation of the 503 error:
http://www.w3.org/blog/systeam/2008/02/08/w3c_s_excessive_dtd_traffic
Still don't know why the parser acesses this resource in the first place - could it be that your remote location returns some kind of HTML response?
Well, the XML parser can be told to ignore dtd when not validating, see here
http://www.w3.org/blog/systeam/2008/02/08/w3c_s_excessive_dtd_traffic#c5266
But: still a checkstyle configuration file does not contain references to a HTML dtd, so this really shouldn't happen.
Because of that I am suspecting that your remote config URL results in a HTML response instead of the actual checkstyle configuration file - for instance because some proxy or so wouldn't allow the Eclipse runtime to access this resource, generating an Html Error page instead.
Pending, awaiting further response/input
I already filed this issue to checkstyle, but was guided to the plug-in. Please, advise how to proceed.
https://sourceforge.net/tracker/?func=detail&atid=397078&aid=3091409&group_id=29721
Have you read my comments? I thought it was mostly clear, a bit chaotic, but well...
Bottom line is that I think the remote URL you configured as your Checkstyle config files resolves to a HTML document (maybe some proxy infrastructure of your company which does that) and not a Checkstyle configuration file.
It is that HTML file which contains the reference to the HTML DTD (a Checkstyle config file does not contain such a DTD reference) hence the parser tries to access the HTML DTD on the internet.
Due to load issues on the W3C site they however forbid the HTML DTD to be accessed, hence the 503 error.
Working Example
Not Working Example
I tried a bit to find more details. I came to the situation where I had a configuration example that was working, but another one which was not (see the attached files) from the same location. The only thing we changed is that we disabled DoubleCheckIdiom and MagicNumbers. As already written, this problem is only appearing on an HTTPS connection with Basic Authentication. On usual HTTP without Authentication or as local file, both configurations are working without any problem.
Could it be a problem of the exported file itself?
Unfortunately, our development environment is located on an HTTPS connection with Basic Authentication, so we are heavily dependent on this.
Sorry, for my previous replies, I was confused about the comments: I didn't realize that it is in reverse order (newest on top). I simply scrolled to the bottom and answered to your first entry, not the last one.
To answer your question: there is no proxy in between, we have a direct HTTPS connection.
Your feeling that it may return an error page sounds reasonable. Unfortunately, I can't check immediately what is downloaded, because it is SSL encrypted. I need to setup something to sniff what pages are sent. This will definitely take some time.
I now checked the configuration files on a different HTTPS server (with self signed certificate) and it is working. Does not seem to be a Checkstyle-Plugin issue.
I'll contact our webhoster to ask them to fix it. Probably they have installed something to handle requests from a browser and from Java differently? Nevertheless, thank you so far to guiding me to the right direction, the example with the proxy-configuration and your explanation. That was helping me a lot to understand the problem. I hope, I'm on the right track now :-)
Thanks for the note, glad my fishing-in-the-mud helped a bit.
Good luck on getting it fully fixed.
Cheers, Lars
Problem solved: the hoster was redirecting the original request: returning an HTML page which was - of course - not a checkstyle configuration file and lead to this error message.
@lkoe: Thank you very much for your quick and competent support.