Item14663: Allow lax / strict URL parsing to be configurable.

Foswiki 2.x accidentally introduced a "lax" parsing of the URL, similar to the topic= URL Param. If only a topic name is specified the web will default. So for example, https://foswiki.org/WebStatistics will resolve to the UsersWeb.WebStatistics topic rather than give the expected Web not found error.

This behavior may or may not be desirable. Foswiki 2.2 actually restored strict URL parsing, fixing the error and resulting in the expected 404. However 2.0/2.1 behavior was convenient and could be a configurable option.

Add a new EXPERT Configuration key: {StrictURLParsing}. Default is disabled (Handle URLs like in Foswiki 2.x). Enable the setting to require the web in the URL, like Foswiki 1.x

-- GeorgeClark - 17 Mar 2018

(Notes from a feature proposal that I hijacked for this particular issue.)

URL Parsing of TopicName

And a 2nd somewhat related issue, I introduced a bug in 2.0.0, when I refactored the URL parsing. It checks the "last component" of the path to see if it's a topic. normalizeWebTopicName will supply a missing web and we end up with a valid path. So as long as a topic name exists in the default web, URLs like https://foswiki.org/WebPreferences works just fine. This is fixed in the upcoming 2.2 - the new Foswiki::Request based parser is strict in how it parses the URL path, and has unit tests to validate it. I can think of 3 choices

• It's a bug. 2.2 will require a Web/Topic in the URL. This will break compatibility with 2.0/1
• It's a reasonable feature. Fix 2.2, so it behaves as 2.0/1
• Make it configurable.

I'm leaning toward 2.

-- GeorgeClark - 06 Mar 2018

Looking into this, a common parser is used for the topic= parameter and the query path, with a flag to specify which it's parsing. So by forcing $topic_flag to true, the code behaves like 2.0/2.1. So this is pretty easy to make configurable.

-- GeorgeClark - 06 Mar 2018

With regard to URL parsing – making it configurable with the default strict mode sounds good enough too.

-- VadimBelman - 07 Mar 2018

-- GeorgeClark - 17 Mar 2018

Commenting is disabled while not logged in