anchor issue

[RobertShiplett]

The English language release notes for 8.0.0 at curl.com appear to me to understate the issue with HTML URL #anchor as in Windows IE and Firefox

For example, this link works in a Curl applet:

{link href={url "http://en.wiktionary.org/wiki/山%23Kanji"}, yama}

but this link does not:

{link href={url "http://www.aule-browser.com/kanji/kanjidic2-joyo-hz-3.html%23kumo"}, 雲 }

It appears that no anchor following a leaf ending with an extension works in any browser.

This link also does NOT work in a Curl applet

{link href={url "http://www.aule-browser.com/kanji/kanjidic2-joyo-hz-3.html#kumo"}, 雲 }

but DOES work in all browsers.

Using {set-leaf } and {set-anchor } and then the final resulting Url object has no effect.

Note that {set-anchor } will not accept %23 in place of '#'.

I have found no combination of {parse-url } or {url-encode-string } which will result in success any more with

{browse-url } than with {link } .

IE's status bar shows that the anchor IS SET as does a dump of this-url.anchor to {output }

Here are 4 test links:

{link href= {url "http://en.wiktionary.org/wiki/%E5%B1%B1%23Kanji"}, TEST1}

{link href= {url "http://en.wiktionary.org/wiki/山%23Kanji"}, TEST2}

{link href= {url "http://en.wiktionary.org/wiki/%E5%B1%B1#Kanji"}, TEST3}

{link href= {url "http://en.wiktionary.org/wiki/山#Kanji"}, TEST4}

Can you show me an address ending in a .html where the #anchor works ?

The problem is not just with {destination } across Curl applets.

Is there a way to make what works here

{link href={url "https://en.wikipedia.org/wiki/Object-oriented_programming_language%23Design_patterns"}, wp}

work for a page such as "Curl_programming_language.html%23Design_patterns"

or

"Curl_programming_language.html#Design_patterns"

or simply

{url-encode-string maybe-has-anchor? = true, "Curl_programming_language.html#Design_patterns"}

??

Note: this DOES work:

{link href={url {url-encode-string "http://en.wiktionary.org/wiki/山#Kanji"}}, yama}

but this FAILS:

{link href={url {url-encode-string "http://www.aule-browser.com/kanji/kanjidic2-joyo-hz-3.html#kumo"}}, cloud}

and this is NO help:

{link href={url {url-encode-string maybe-has-anchor? = true, "http://www.aule-browser.com/kanji/kanjidic2-joyo-hz-3.html#kumo"}}, cloud}

To make matters worse, how are we to interpret this documentation? It reads, quote:

"
possibly in combination with the maybe-has-query? and maybe-has-anchor? parameters.

maybe-has-query?: This parameter is for Curl, Inc. internal use only, and should never be supplied.
"

Are we able to ask: Which is it? Possibly With? Or is it Should Never Be Supplied ?

And no, {canonicalize } has been of no use in this matter.

[wbardwell]

The trouble with anchors is that many browsers have (in the past anyway) behaved very badly when URLs to non-HTML pages had anchors, and especially when file: Urls had anchors. So the code strips off the anchor and then has special code to make it take effect for Curl applets.
There might be a way to double encode the anchor and get it to work, but there may not be, you can experiment. This issue was the collateral damage for getting browsing to Curl applets to work better.

Those two maybe-* parameters just make the code look for a # and a ? and if it finds those it skips
encoding starting at which ever of them is first. Setting either of them will not help your issue, because they make it encode less, not more. (Basically they can be used when encoding a string that might already be encoded, but doing that is kind of dangerous unless you know more about the state of the string.)

[RobertShiplett]

Thanks - it seems to do no harm done in trying to reach an anchor - since they can be reached in some cases.

Good to hear from you. Hope all is well with you this summer.

btw, I have a lovely red maple out my window ( kaede かえで 楓 CAEDE )

regards