Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Changes in URL encoding/decoding?
#1
Hi,

since migrating from IW 15.1.15 to 15.2.49 we have noticed that there seems to be a change on how URL parameters are (automatically) decoded when containing non-basic characters. While I did a quick fix for a specific case where '+' was encoded as '%2B', we have discovered another case where users themselves have been able to encode non-English characters in a parameter, e.g. '%C3%B6' for 'ö', where our old code is no longer working. When I look at our code, the parameter values have been accessed either by using WebApplication.RunParams.Values or WebApplication.Request.QueryFields.Values, but in both cases it now seems that characters encodings now appear there without being decoded.

In IW 15.2.49+, what is the correct way of handling URL parameter decoding? Do I need to change some setting or add some code in order to get it to work like before?

Best regards

Magnus Oskarsson 
Reply
#2
Is this part of a normal GET request when the application is running or you are specifically reading the parameters used to start the application?
Reply
#3
(03-02-2022, 01:33 AM)Alexandre Machado Wrote: Is this part of a normal GET request when the application is running or you are specifically reading the parameters used to start the application?

It is only for reading the parameters used to start the session. I did a fix to wrap the calls getting the URL parameters with TIdURI.URLDecode() calls, but it is still interesting to know how you are intended to handle this in the best way with new IW versions.
Reply
#4
The point here is that they need to be stored in their original form, the same way that they have been received. There are special cases where the start parameters need to be included in the URL again (e.g. redirections).

Due to the mess that URL encoding is in the real world where the standards are not exactly followed (e.g. should + be encoded or not?), the safest way to create such redirections which need the same start params is to keep them as they were received, without any decoding/encoding in the middle.

Maybe we should introduce a new method to retrieve the start parameters in a decoded form, so it would be 100% compatible with existing code (although the method name would eventually change, but the functionality would be identical)
Reply
#5
Thanks Alexandre for the explanation!
Reply


Forum Jump:


Users browsing this thread: 2 Guest(s)