WA Get last filtered URL returns invalid URL

I’ve recently converted our web areas from the system engine to the embedded Blink engine and found that WA Get last filtered URL behaves (I think) incorrectly with the embedded engine.

Given the following filtered url,
the command returns the string with the encoded special characters resolved to their actual character, e.g.
file:///C:/Desktop Folder/4D v18/Sandbox.4dbase/Resources/test.html?key=This&that
which is not a valid URL.

This means that I can’t parse the query string since I don’t know whether the & character is part of the value of key or signifying a new key called that.

Has anyone else encountered this issue?

My testing has been on Windows 10 with v17 R6 and v18.


Test on my system show same behavior
4DV18.0build249095 MacOSX10.13.6

Case of
  : ($form_event=On URL Filtering)
    $LastFilteredURL:=WA Get last filtered URL($ptrWAvar->)  // gets decoded URL

    Case of
        OPEN URL($LastFilteredURL)  // 4D auto encodes the URL

    End Case

End case


Thanks Lutz. Glad it’s not just me.

WA Get last filtered URL definitely shouldn’t be decoding anything. It should be returning the exact filtered URL.

Consider the URL https://mydomain.com/page.html?q=this%26that%3Dstuff&r=6
The value of q is this&that=stuff and the value of r is 6.

But if that URL is filtered in a web area, WA Get last filtered URL returns https://mydomain.com/page.html?q=this&that=stuff&r=6
Now the value of q is this, plus there is a new key in the query string that which has the value stuff.

When I passed that filtered URL to OPEN URL it didn’t encode the query string so it opened the URL with the wrong query string. It makes sense that it wouldn’t encode the & and = characters in the query string as that would make the query string invalid.

WA Get last filtered URL needs to do the same thing as OPEN URL and leave the query string unchanged.


Yes i think too the decoded url version of “?q=this%26that%3Dstuff&r=6”
must maybe total same as encoded one
and it is maybe a mistake to translate %26(&) %3D(=) inside a q-par-value.
And i think too, maybe it is better all Get-URL commands gets the original encoded URL and not the translated to decoded url one.

And i think too, maybe it is better all Get-URL commands gets the original encoded URL and not the translated to decoded url one.

I agree. When I have time I might raise it on TAOW.


Maybe this infos helps a little bit (or maybe it only confused, i do not know :wink:

A exotic example for a url query string:


A user maybe search for text contains exactly this string “title=Oliver&Co”
( =& critical chars inner value of a URL query parameter needs percent-encoding )
…and in category “animated musical film”.

Only one example in javascript:


This returns decoded URL in respect to NOT decode the value parts in query string!
https://www.test.com/test space.html?q=title%3DOliver%26Co&category=animated+musical+film”

Turn this decoded result back into encoded one:
encodeURI(‘https://www.test.com/test space.html?q=title%3DOliver%26Co&category=animated+musical+film’)
This fails because all percent-symbols in the value of a URL query parameter
now percent-encode (example “%3D” -> “%253D”).

Use “encodeURIComponent” only for separatly encode the value of a URL query parameter.
Only the VALUEs of a URL query parameter must encode/decode separat
(split url and queryString before encode/decode it in parts).

Take a look here too:

Thanks Lutz.

encodeURIComponent is what I’m using to encode the individual query parameter values in the web area page, no issues there.


Only issue is getting the correct URL that was filtered when input contains & characters.