JDK-5012874 : wrong proxy type returned when file URL is used instead of http URL
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 1.4.2_03
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: solaris_2.6
  • CPU: x86
  • Submitted: 2004-03-12
  • Updated: 2004-07-22
  • Resolved: 2004-06-22
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
1.4.2_06 06Fixed
Related Reports
Relates :  
Relates :  
Description
The following returns 1 (which is MANUAL)

temp = System.getProperty("javaplugin.proxy.config.type");

when we use java plugin 1.4.2 with "Use Broswer Setting" set to true
(in the plugin control pannel) and the browser has a PAC file URL
in the form of a file URL, like file:///c:/new.pac.

Whereas instead of returning 1 System.getProperty should return 2,
which is AUTO.

A file URL pointing to Auto Configuration Script is a valid PAC location.

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.4.2_06 generic tiger-rc FIXED IN: 1.4.2_06 tiger-rc INTEGRATED IN: 1.4.2_06 tiger-b57 tiger-rc VERIFIED IN: 1.4.2_06
23-07-2004

SUGGESTED FIX See webrev at http://javaweb.sfbay/~xl116366/webrev/5012874. ###@###.### 2004-05-20
20-05-2004

EVALUATION The root cause of the problem is file://c:/ is not recognized by Java as a valid file url based on RFC 1738 and RFC 1630. file://c:/ should be file://c|/ based on the standards. However, that won't be recognized by the browser. So we need to somehow convert it to standard after we get the url from browser. More investigation about the risk of fix is taking place. ###@###.### 2004-03-15 Microsoft uses its own DOS file URL format, it does not conform to w3c file URL standards. Also I think it does not worth to fix this issue since it is a Microsoft compatibility issue and using file:// in Enterprise is not possible plus Microsoft does not support file://host/path either. ###@###.### 2004-03-15
15-03-2004