This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
| Summary: | ExternalBrowser does not handle space in directories | ||
|---|---|---|---|
| Product: | ide | Reporter: | Jaroslav Tulach <jtulach> |
| Component: | Internal Server | Assignee: | Petr Jiricka <pjiricka> |
| Status: | CLOSED DUPLICATE | ||
| Severity: | blocker | CC: | jglick |
| Priority: | P2 | Keywords: | SPACE_IN_PATH |
| Version: | 3.x | ||
| Hardware: | Other | ||
| OS: | Windows 95/98 | ||
| Issue Type: | DEFECT | Exception Reporter: | |
| Attachments: | 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. | ||
|
Description
Jaroslav Tulach
2002-07-14 21:08:53 UTC
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 Set target milestone to TBD This may be related to (or duplicate of) 25601, need to investigate. "%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 corrective action. 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 following: http://pjiricka-ws:8083/resource/nbfs% 3Aorg.netbeans.modules.javacvs.JavaCvsFileSystem+EQCQDtrans ferQDbugsQD25610QDTatry/1.+den+-+Rysy/index.html 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: http://pjiricka-ws:8083/resource/nbfs%3Aorg.netbeans.modules.javacvs.JavaCvsFileSystem+EQCQDtransferQDbugsQD25610QDTatry/index.html 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 encoded: <a href="1. den - Rysy/index.html">Rysy</a> It should be: <a href="1.+den+-+Rysy/index.html">Rysy</a> 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. |