"Use a Checkstyle file accessible via HTTP" option does not support HTTP redirects such as 302 and 307

[craigalansmith]

Using version 5.114.0 of the CheckStyle-IDEA plugin in Intellij IDEA 2025.2 (Ultimate Edition).

I attempted to use a download link to the "latest" version of a rules file, from a well-known repository manager system.

This failed - after clicking "next" on the Add Configuration dialog, I get "Loading the rule file caused an error" with the output below.

Pasting the link into the browser verifies that the address is valid and returns a correct rules file.

Downloading the file and loading it into the plugin via the "Use a local CheckStyle file" option works - this confirms the file is valid.

Accessing the download link using curl shows that the link is actually returning a series of HTTP redirects - codes 302 and 307 - which eventually take us to a link to a specific version, which then returns the xml file with an http response header of "application/xml".

So the question is - can the CheckStyle-IDEA plugin be changed so that it can handle HTTP redirects such as 302, 307 (possibly also others such as 301 and 308) on the url specified in the "Use a CheckStyle file accessible via HTTP" field?

Regards,
Craig

	at com.puppycrawl.tools.checkstyle.ConfigurationLoader.loadConfiguration(ConfigurationLoader.java:308)
	at com.puppycrawl.tools.checkstyle.ConfigurationLoader.loadConfiguration(ConfigurationLoader.java:273)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
	at java.base/java.lang.reflect.Method.invoke(Method.java:580)
	at org.infernus.idea.checkstyle.service.cmd.OpLoadConfiguration.loadConfigurationForCheckstyle825AndAbove(OpLoadConfiguration.java:180)
	at org.infernus.idea.checkstyle.service.cmd.OpLoadConfiguration.callLoadConfiguration(OpLoadConfiguration.java:148)
	at org.infernus.idea.checkstyle.service.cmd.OpLoadConfiguration.execute(OpLoadConfiguration.java:131)
	at org.infernus.idea.checkstyle.service.cmd.OpCreateChecker.loadConfig(OpCreateChecker.java:69)
	at org.infernus.idea.checkstyle.service.cmd.OpCreateChecker.execute(OpCreateChecker.java:48)
	at org.infernus.idea.checkstyle.service.cmd.OpCreateChecker.execute(OpCreateChecker.java:23)
	at org.infernus.idea.checkstyle.service.CheckstyleActionsImpl.executeCommand(CheckstyleActionsImpl.java:114)
	at org.infernus.idea.checkstyle.service.CheckstyleActionsImpl.createChecker(CheckstyleActionsImpl.java:58)
	at org.infernus.idea.checkstyle.service.CheckstyleActionsImpl.createChecker(CheckstyleActionsImpl.java:50)
	at org.infernus.idea.checkstyle.checker.CheckerFactoryWorker.run(CheckerFactoryWorker.java:37)
Caused by: org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 1; Premature end of file.
	at java.xml/com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:204)
	at java.xml/com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.fatalError(ErrorHandlerWrapper.java:178)
	at java.xml/com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:400)
	at java.xml/com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:327)
	at java.xml/com.sun.org.apache.xerces.internal.impl.XMLScanner.reportFatalError(XMLScanner.java:1465)
	at java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$PrologDriver.next(XMLDocumentScannerImpl.java:1013)
	at java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:605)
	at java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:542)
	at java.xml/com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:889)
	at java.xml/com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:825)
	at java.xml/com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:141)
	at java.xml/com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1224)
	at java.xml/com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:637)
	at com.puppycrawl.tools.checkstyle.XmlLoader.parseInputSource(XmlLoader.java:85)
	at com.puppycrawl.tools.checkstyle.ConfigurationLoader.parseInputSource(ConfigurationLoader.java:186)
	at com.puppycrawl.tools.checkstyle.ConfigurationLoader.loadConfiguration(ConfigurationLoader.java:302)
	... 13 more

[jshiell]

I've just tested it using a local nginx returning a 302; a 307; and a chain of both, and it handles those cases by following the redirects. Internally we use URLConnection, and the docs confirm that redirect handling is turned on by default. So the immediate answer is redirects should be good.

However, I can reproduce this using a non-error (i.e. < 400) response code without a body such as 204 or 304, as we just pass the body stream to be used by the parser once we get a response.

Could there be anything else in the chain that might give us a response with no body?