baseHref not correctly treated -- new solution

[guest]

I have a proposed solution for the problem created by changeset:928 which I explain in detail in the last comment to ticket:961. In summary, the problem is that the "fix" introduced in this changeset trashes the domain if baseHref is set to a domain with no final / (the domain is stripped from the regex beging constructed here, leaving just "http://", which is catastrophic). The fix also incorrectly strips any directory that does not end in /.

My solution is to change the regular expression from:

replace(/\/[^\/]*$/, '/')

to this smarter version:

replace(/([^\\/]\/)(?=.+\.)[^\\/]*$/, "$1")

Explanation: This regex first of all searches for any NON "/" character followed by a literal "/". This avoids matching the "//" in "http://", so we don't trash the domain. The parentheses save the non-/ and the / in backreference $1. It then uses the positive lookahead «(?=.+\.)» to assert a match ONLY if the characters between the matched "/" and the end of the string contain a period (e.g., ".html" ".php" ".anything"). If a period is found then match to the end of the string «[^\/]*$» (unless there's another "/", in which case the match process will fallback to the new "/", etc., until a match is found or the match fails). The replacement $1 (if a match was found) will always contain "x/" (where x is any letter that was matched immediately before the "/").

The above solution should work in all common situations, and will even work with "http://www.mydomain.com/cgi-bin/hello.php?version=5.2", where the result will be "http://www.mydomain.com/cgi-bin/" (i.e., this is the string that will be stripped from links). The only case in which it would fail is if someone is serving files with no . extension (.html, .php, .etc). But in that case, they should be well aware of the ambiguity of setting baseHref to "http://www.mydomain.com/myfile" (is it a file or a directory?), and can resolve it easily by leaving off the "myfile" bit. This solution also has the virtue of respecting the existence of a final "/" or not (it won't add one if there wasn't one on the end of the domain), allowing us to continue using semi-relative links of the style <a href="/mydir/myfile.html"> in Xinha.

I hope this can be included in a forthcoming changeset. - Geoffrey K

[guest]

I've just noticed the proposed .replace string above has some redundant backslashes. Should read:

replace(/([^\/]\/)(?=.+\.)[^\/]*$/, "$1");

Apologies. Geoffrey K

[ray]

rev [940]: I hope your fix is good, because I just put it in without understanding anything of this stuff