Preserving URL with an Escape character?

#1

1) Give a description of the problem
I have a simple URL that will not stay the way I type it. I need a portion of it to be:
us&region
but everything I have tried converts it into:
us®ion
So the web request fails.

2) Notes
I have tried using a backslash as an escape character, but no luck. I have tried splitting it up into two variables, but when I eventually join them together, it corrupts the address again.

3) Post a Green Snapshot of the piston
temp

This sounds so simple, but I am having a blonde moment.
Surely someone can shed some light on this for me?

Thanks in advance.

#2

Cheat and urlEncode it :slight_smile:

oops, if you mean in the editor — I encountered this once a long time ago, not sure how we got around it

#3

Yea, both us%2526region and us%26region failed.

#4

I’m intrigued… going to try it

#5

Oh happy days!!
&
was the secret to replace the &

#6

Hate it when works interfere with playing :smiley:

#7

I found it, it would’ve bugged me all day :stuck_out_tongue:

#8

Sorry for the confusion guys but I don’t see any reason why changing the URL from &region=ca to &region=ca would cause a web request to work better. This does not make sense, by changing the URL to avoid the webCoRE display issue you are changing the URL used for the request. It’s going to send &region=ca in the request. You can use requestcatcher.com to see the actual request performed by webCoRE when debugging the web request action.

By this:

The fix is replacing & with & in any user input that is displayed as HTML, in a way that does not interfere with any of the webCoRE content.

what I meant was that in order to fix the display issue the dashboard’s JavaScript code would need to replace those & characters with &. It’s not something that you as a user should do in your piston, but rather a future bug fix tip for contributors to the dashboard web app.

#9

Right you are. When I use &, the display looks right, but the web request fails. When I use &, the display looks wrong, but the request goes thru successfully.

Sometimes I forget that the display does not always match the underlying code exactly.

#10

This gets even trickier if you’re using the Expression field rather than Value. The Expression input has longstanding problems of rendering text as HTML code… so if you type something like <strong> in an expression it instantly gets converted to the HTML tag and the text disappears. The biggest problem is that the normal text input over which the expression editor displays still has the <strong> as text, so the editing caret ends up disconnected from the displayed text.

The same thing happens with your example so I recommend if you are seeing this to stick with Value rather than Expression. Otherwise, things get very weird

expression-html
expression-html.gif748×108 488 KB

The expression editor shows the code with syntax highlighting over a transparent text input. The | caret is from that text input so you can see here that the value continues to be typed in normally but since the caret position does not match the display it’s impossible to use.