Where "YearAgoDate" and "YearAgoDatePlusOne" are my variables (which look correct). However, the resulting string that actually gets opened in the browser is:
Why is it including the word "Variable" there? I can work around it by doing a search and replace in the variable, replacing "Variable " with an empty string. But it seems something's really wrong that I have to do that. Is it breaking because the thing I'm inserting it into already has % signs? Should I be escaping something?
To simplify the input a bit, we can swap out the percent-encoded character "%3A" for its decoded equivalent, which is a colon, and a perfect legitimate character to use in the URL's path of an http protocol.
The second thing I did in my experimenting was to get rid of the word "Variable", but keep the percent characters. Thus, %Variable%YearAgoDate% would become %%YearAgoDate% (note the two preceding percent characters).
In your specific example, we don't need to concern ourselves with validating the URL, as your variables contains ISO-formatted dates in the form YYYY-MM-DD, which don't contain any reserved characters that would need encoding after the text tokens have been processed.
If, however, your variables might contain more erratic strings, consider using the Filter action (found under Variables), which has an option to Percent Encode for URL, which will produce a valid URL string with the text tokens processed and encoded correctly.
But, the current URL I've given should be fine to use "as is". (see below)
Well... I completely balls'd that up, because it turns out that Keyboard Maestro doesn't adhere to the defined specifications for URLs as laid out by whomever it is that defines these things in an official capacity.
It appears the URL field for the Open URL action just establishes a blanket ban on all characters that feature in a reserved character list for any part of the URL, which means it doesn't like the colon being used in the URL's path, because for the URL's scheme, the colon is a reserved character.
So, ignore my advice to swap out the percent-encoded character "%3A"; that does have to stay where it is. Therefore, the valid URL will now look like this:
No, that's actually the reverse of the problem. Keyboard Maestro relies on NSURL to parse the URL, and NSURL very strictly adhere's to the requirements.
When processing text in a field, the % character is special, it is used to denote the tokens in the field.
So anywhere you want a plain % in the result, you need to double the % character.