Bug 25610 - ExternalBrowser does not handle space in directories
ExternalBrowser does not handle space in directories
Status: CLOSED DUPLICATE of bug 25601
Product: ide
Classification: Unclassified
Component: Internal Server
3.x
Other Windows 95/98
: P2 (vote)
: -S1S-
Assigned To: Petr Jiricka
issues@ide
: SPACE_IN_PATH
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2002-07-14 21:08 UTC by Jaroslav Tulach
Modified: 2003-07-01 09:34 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
:


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. (6.22 KB, application/octet-stream)
2002-07-14 21:10 UTC, Jaroslav Tulach
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jaroslav Tulach 2002-07-14 21:08:53 UTC
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 " "...
Comment 1 Jaroslav Tulach 2002-07-14 21:10:28 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.
Comment 2 Marek Grummich 2002-07-22 09:15:48 UTC
Set target milestone to TBD
Comment 3 Marek Grummich 2002-07-22 09:18:14 UTC
Set target milestone to TBD
Comment 4 Petr Jiricka 2002-07-22 09:44:58 UTC
This may be related to (or duplicate of) 25601, need to 
investigate.
Comment 5 Jesse Glick 2002-07-25 17:43:23 UTC
"%20" is not right AFAIK, should be "+" in standard URL encoding.
Comment 6 Jaroslav Tulach 2002-07-26 07:39:12 UTC
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.
Comment 7 Jaroslav Tulach 2002-07-26 07:58:23 UTC
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.
Comment 8 Petr Jiricka 2002-07-26 10:13:29 UTC
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 ***
Comment 9 Jaroslav Tulach 2002-07-26 11:08:33 UTC
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.


Comment 10 Petr Jiricka 2002-07-26 12:55:13 UTC
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. 

Comment 11 Jesse Glick 2002-07-29 02:36:15 UTC
"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).
Comment 12 Jason Rush 2002-07-30 23:02:53 UTC
Verified in Sierra build 020729_ee.
Comment 13 Quality Engineering 2003-07-01 09:34:50 UTC
Resolved for 3.3.x or earlier, no new info since then -> closing.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo