Lagrange and Scriptonite
After carrying on for weeks thinking Scriptonite was just fine and dandy, I find out a number of my sample scripts don't work in Lagrange.
Long story short, my auto-prompt scheme relies on redirects. Right or wrong (someone tell me), Alhena redirects with the exact url sent in the status 30 message. It appears Lagrange will decode things in the url I intended to be preserved.
Simple example: If my server builds a redirect url containing ";code=2%2B2", it becomes ";code=2 2" when Lagrange handles the redirect because '+' or %2B decodes to a space.
If I enter this into my dynamic scripting page:
In Ahena, the resulting code variable ends up in the redirected url like this:
Using Lagrange, the server ends up prompting for 'm' because the ';' got decoded and ';' is used to delimit url parameters. (I entered "test" for m and then the final url looks like):
It leaves the space encoded as %20 but not the single quotes or the semi-colon (the single quotes are probably fine). Needless to say, this doesn't work.
Not everything breaks. I redid the prompts for Scripto-Zoe so there were no special characters in the prompt text (it seems "[" and "]" break things). Now it works fine. Other things are more problematic: 2+2 doesn't work on the dynamic scripting page but you can enter 2 - 2 and get an answer. Semicolons are a no go in variables.
Now it could be that Alhena should also be decoding these characters on redirect and the whole scheme was broken to begin with. I'm not sure though. Any thoughts? Unfortunately a simple workaround hasn't occurred to me. If I require special encoding for these params (base64, etc), links won't be as easy to create or read.
2025-07-31 · 9 months ago
3 Comments ↓
🌆 skyjake [...] · 2025-07-31 at 06:50:
It seems to me that the correct behavior is the redirected URL is kept percent-encoded when doing the request. If Lagrange is decoding the redirected URL, it's probably a bug.
I'll need to investigate how the semicolon specifically is handled internally in this case.
🛸 bluesman [OP] · 2025-07-31 at 12:44:
Thanks. This log helped me make sense of it. The first line is the redirect url created by the server. The second line is what the server gets from the client moments later. The third line is the "cleanup" redirect with the last being the result from the client. The issue is the handling of the "code" segment.
Alhena
Lagrange
So basically Lagrange isn't removing the '+' but it is removing the percent-encoding. (It's the server that removes the '+' when decoding. That's why it becomes %20 in the second redirect). The same happens with other chars encoded in redirect urls.
🛸 bluesman [OP] · 2025-08-01 at 19:21:
It's not just redirects affected - or rather, erroneous redirects are a side effect. Give the following link:
Lagrange will interpret it as:
Even hovering the mouse over the link shows this alteration in the status bar.