JDK-8190312 : javadoc -link doesn't work with http: -> https: URL redirects
  • Type: Bug
  • Component: tools
  • Sub-Component: javadoc(tool)
  • Affected Version: 9
  • Priority: P3
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2017-10-27
  • Updated: 2018-01-09
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.
Other
tbd_majorUnresolved
Related Reports
Relates :  
Relates :  
Description
It seems like everybody is moving from http to https as the preferred protocol (good!) BUT:

If I use javadoc -link with http: URLs the output for e.g. java.util.List in """All Implemented Interfaces""" is NOT linkified, whereas with https: it works fine.

I notice today that attempting to visit
http://docs.oracle.com/javase/9/docs/api/java/util/ArrayList.html
is "autocorrected" (redirected?) to use https instead
https://docs.oracle.com/javase/9/docs/api/java/util/ArrayList.html
which might possibly be related.

Demo:

 $ (for file in JavadocLinkBug.java Makefile; do cat $file; echo ---; done; make clean 9; /usr/bin/google-chrome --incognito --user-data-dir=/tmp/chrome-view-url.gtWVr7Vd7Z --allow-file-access --allow-file-access-from-files --no-first-run file://${PWD}/JavadocLinkBug.html)
public abstract class JavadocLinkBug implements java.util.List {}
---
JDK9 = ~/jdk/jdk9
JDK10 = ~/jdk/jdk10

9:
	$(JDK9)/bin/javadoc -link http://docs.oracle.com/javase/9/docs/api/ JavadocLinkBug.java
10:
	$(JDK10)/bin/javadoc -link http://docs.oracle.com/javase/9/docs/api/ JavadocLinkBug.java
9-https:
	$(JDK9)/bin/ javadoc -link https://docs.oracle.com/javase/9/docs/api/ JavadocLinkBug.java
10-https:
	$(JDK10)/bin/javadoc -link https://docs.oracle.com/javase/9/docs/api/ JavadocLinkBug.java

clean:
	rm -rf *.html *.js *.css *.zip resources/ jquery/ package-list

.PHONY: 9 10 9-https 10-https clean
---
rm -rf *.html *.js *.css *.zip resources/ jquery/ package-list
~/jdk/jdk9/bin/javadoc -link http://docs.oracle.com/javase/9/docs/api/ JavadocLinkBug.java
Loading source file JavadocLinkBug.java...
Constructing Javadoc information...
Standard Doclet version 9.0.1
Building tree for all the packages and classes...
....
Comments
If it does not already do so, javadoc should detect/report any connection issues with the given URL, and should maybe try and give "friendly" messages for common cases of failures.
2017-12-13

Any affected user can usually fix their own problem by switching from http: to https: and we did that in the jsr166 project. But many users will be affected without understanding the problem, and their javadoc links will silently stop working.
2017-11-10

We conjecture that the package-list handling in jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Extern.java needs to handle redirects, or at least redirects between http: and https: private void readPackageListFromURL(String urlpath, URL pkglisturlpath) throws Fault { try { URL link = pkglisturlpath.toURI().resolve(DocPaths.PACKAGE_LIST.getPath()).toURL(); readPackageList(link.openStream(), urlpath, false);
2017-10-31

We conjecture that the failure is due to URLConnection not following redirects, as was decided long ago. Perhaps javadoc has the responsibility of following redirects?
2017-10-31

URLConnection does not follow redirects. ###@###.### 2002-01-29 After discussion among Java Networking engineers, it is felt that we shouldn't automatically follow redirect from one protocol to another, for instance, from http to https and vise versa, doing so may have serious security consequences. Thus the fix is to return the server responses for redirect. Check response code and Location header field value for redirect information. It's the application's responsibility to follow the redirect. ###@###.### 2002-04-12
2017-10-31