It seems that there is a bug in httpserver/extrnalbrowser
integration. If on Win98 I try to open my own html page on javacvs
filesystem the explorer tries to connect to
"http://localhost/javacvs/path%20with%20space/thepage.html" and the
httpserver is not able to resolve such request. I suspect the "%20"
is not converted to " "...
Created attachment 6657 [details]
Unzip, mount as JavaCVS filesystem and open Tatry/index.html in external browser. Try the first link (Rysy) and you will see it is broken even the file exists.
Set target milestone to TBD
This may be related to (or duplicate of) 25601, need to
"%20" is not right AFAIK, should be "+" in standard URL encoding.
Tell it to M$ engineers. I need this to be fixed, either on NetBeans
or M$ side. I just thought it will be easier to ask here.
This bug is reported in version <= 3.4dev and still not fixed. Due to that it
forbids the release candidate for 3.4 to be promoted. Are you aware of that and
are you intensively working on the fix? If not, you should consider some
This is now fixed in both trunk and sierra. Fix for
NetBeans 3.4 is not needed.
The fix is to encode and decode the URL in the HTTP server
module. So the URL computed by this approach is the
This URL is served correctly by the internal server.
In addition to this, the fix for issue 25609 ensures that
the HTTP server is not called and started at all. So the
real URL passed to the browser is a local file: URL.
*** This issue has been marked as a duplicate of 25601 ***
Does this mean that if I in main trunk open enter the url:
and click the link Rysy (in explorer on windows) I will be sent to URL
that you have decribed? I do not think so. But I cannot verify it
right now. I'll do it at the evening and verify/reopen as appropriate.
No, this is not guaranteed. The reason is that the link in
the HTML page in the attached example is not correctly
<a href="1. den - Rysy/index.html">Rysy</a>
It should be:
Some browsers may correctly convert the URL in the page to
a compiliant encoded URL, other browsers may not. Please
try this and let me know. It works in my environment.
"Some browsers may correctly convert the URL in the page to a
compiliant encoded URL, other browsers may not." - AFAIK it is not the
browser's job to "convert" the URL; the HTML must be correctly
URL-encoded in the <a> tag to begin with. If a browser converts bad
HTML it is a browser feature (robustness of HTML interpretation).
Verified in Sierra build 020729_ee.
Resolved for 3.3.x or earlier, no new info since then -> closing.