Item11025: Foswiki should be able to handle Anchor before URL param in the same calling URL

I have a test topic set up at Sandbox/VbTest1.

It contains

• 4 anchors, #AnchorOne, #AnchorTwo, #AnchorThree, #AnchorFour
• code to check the value of a URLPARAM named var
• enough body content to make the page long enough that jumping to an anchor is obvious.

If you access the page as http:.../Sandbox/VbTest1#AnchorFour
Then you jump to the 4th paragraph.

If you access the page as http:.../Sandbox/VbTest1?var=42
Then %URLPARAM{"var"}% is seen and the value is displayed

If you access the page as http:.../Sandbox/VbTest1#AnchorFour?var=12
Then neither the anchor jump nor the URLPARAM is recognized or triggered.

Test

• http://foswiki.org/view/Sandbox/VbTest1#AnchorFour

• http://foswiki.org/view/Sandbox/VbTest1?var=42

• http://foswiki.org/Sandbox/VbTest1#AnchorFour?var=42

-- VickiBrown - 05 Aug 2011

Note that the anchor must always be at the end: http://foswiki.org/Sandbox/VbTest1?var=42#AnchorFour

-- ArthurClemens - 05 Aug 2011

Wow! I learned something new. That's ... unexpected behaviour but OK. I can live with it. I knew someone would come through and give me a way to solve this.

I do wonder though. Given Foswiki is a CGI and sees the URL before handing things to the Browser, couldn't Foswiki bypass this restriction so that a more "expected" (expected if I'm not digging into the W3 spec) URL also works?

-- VickiBrown - 06 Aug 2011

A web search indicates that some browsers handle #Anchor?querystring and some do not. The same search indicates that most people EXPECT the #anchor to be first, followed by the ?parameters.

Thus, not handling #Anchor?queryparam clearly violates the Principle of Least Astonishment.

-- VickiBrown - 06 Aug 2011

Some browsers may be intelligent enough to interpret an anchor before a query string, but oficially a fragment identifier component is indicated by the presence of a number sign ("#") character and terminated by the end of the URI. ( see also http://www.ietf.org/rfc/rfc2396.txt )

So is your proposal that Foswiki rewrites wrongly spelled urls?

-- ArthurClemens - 07 Aug 2011

RFC:2396 is very clear - '#' is the final delimiter after which the fragment identifier is expected. - I studied it deeply for the Foo@123 syntax in LoadDifferentTopicVersions

There is some merit to the argument that Foswiki should perhaps re-write the URL for us. However, Foswiki::Render is already so very full of maddening re-write spaghetti...

Not to mention that a valid anchor name/fragment identifier may legitimately contain '?'

-- PaulHarvey - 07 Aug 2011

FWIW it is my dream that Foswiki will one day auto-compete anchor names (web/topic names coming soon, I hope) in the editor...

-- PaulHarvey - 07 Aug 2011

So, some fool on a standards committee set a totally unacceptable, unguessable, disturbingly wrong situation in stone and we just let that ride, even if we can override it and make lfte easier for users. Terrific.

-- VickiBrown - 07 Aug 2011

> So is your proposal that Foswiki rewrites wrongly spelled urls?

No. My proposal is that Foswiki fix a stupidity that was put into an RFC in 1998.

Great gods. Seriously! 1998???

-- VickiBrown - 07 Aug 2011

-- RichMorin - 07 Aug 2011

There is ample precedent for supporting webbish syntax which may not follow the standard, but agrees with many users' notion of how things should work (ie, Principle of Least Astonishment). Also, it appears that a substantial number of web sites already handle both forms.

However, this is a "corner case" which few users are likely to hit, even in Foswiki. Vicki is a full-time Wiki Gardener and this is the first time she has run into it. So, I can't say that fixing this is terribly important, let alone urgent.

However, there should be a way for the user to find out (a) what is going on and (b) how to resolve the problem. So, I'd like to suggest that the parsing code emit an informative error message (possibly in some sort of "verbose" mode) and that a cautionary note be added to the relevant documentation. In line with this, I am posting an enhancement request for a "verbose" mode.

-- RichMorin - 07 Aug 2011

What would also help, perhaps, is syntax highlighting in the editor. Something else I haven't had time to get to...

-- PaulHarvey - 07 Aug 2011

There is a good reason for standards - and RFC:2396 is marked Category: Standards Track - So it's a standard, and really should be followed. Otherwise ... http://xkcd.com/927/ I don't support that Foswik should diverge from the standards. The solution would be to propose that the IETF amend the standard. Anyone can write an RFC, as it is indeed a request for comments. Some have more legitimacy than others. ie RFC:1925 - but if it's a "Standards Track" RFC then it carries significant weight.

If we choose to "extend" the standards, then it should be configurable and disabled by default.

-- GeorgeClark - 08 Aug 2011

this is another of those things that should go into the error/advice reporting module that Rich or Andrew suggested

-- SvenDowideit - 28 Oct 2011

Commenting is disabled while not logged in