January 2022 PBI RS: Parameter values from query string are not properly decoded in RDL report

[SagarSalvi]

We found this issue when we upgraded from May 2021 to Jan 2022. We are loading RDL report in our application using iframe. We are using report URL and pass parameters in query string. Since URL have parameter and its value, we are doing URL encode before setting iframe source. 

Example:

https://reportserver/reports/report/Customerfolder/TestReport?ConnectionString=server%3dSQLServerNam...

Here parameter ConnectionString value is server%3dSQLServerName%3b+initial+catalog%3dTESTDB

Parameter value used to get properly decoded in all previous versions:





In Jan 2022 this seems to be broken. It decodes everything except +

Anyone seeing this issue with January 2022 PBI report server?

[d_gosbell · Accepted solution]

---

@SagarSalvi wrote:

 We are expecting fix from reporting module.

 

---

Then you really need to log an official support ticket.

I did a quick test with HttpUtility.UrlEncode and UrlDecode and I can confirm that the encode does use + to encode spaces and the decode works correctly with this so to me it does look like a bug of some sort. But only Microsoft support could confirm if this is a bug or a specific design decision.

I can tell you that 2 possible work arounds are to either use %20 for space encoding or to use the /reportserver endpoint instead of the /reports one, but if you want Microsoft to consider a code fix on their side a support ticket is the best approach.

[Petebro · Accepted solution]

Wanted to reply that this has been fixed and will be released in the May release of Power BI Report Server.

[Petebro · Accepted solution]

Wanted to reply that this has been fixed and will be released in the May release of Power BI Report Server.

[SagarSalvi]

Hi Petebro,

Today we installed PBI RS May 2022 to test this issue, but it seems this issue persists. Can you please confirm if this issue was actually fixed and included in May 2022?

Thanks.

[Petebro]

This was fixed and validated. However, it seems in our fix we handled it for most cases, but there is an edge case that unfortunately you are hitting. We are investigating that now. 

[SagarSalvi]

Thank you @Petebro for looking into this. Let us know whenever you any updates on this issue. We are kind of blocked with PBI RS upgrade on our production. 

[SagarSalvi · Accepted solution]

Thought to update this post. This issue is fixed by MSFT in PBI RS September 2022.

[SagarSalvi]

Yes, we contacted MSFT for this issue and worked with their team. They accepted this as an issue on their side and committed that it will be available in May 2022 release.

[v-henryk-mstf]

Hi @SagarSalvi ,

Please let me know if there are any further updates. Looking forward to your feedback.

Best Regards,
Henry

[SagarSalvi]

@D_W thank you for taking a look at the issue. Actually its one of our module which generates the URL dynamically and it uses HTTPUtility.URLEncode(). This module is not touched since long time bcoz everythings working fine uptil now. We are doing monthly releases and now we have 100s of different versions. All our customers are on different version. Its wont make sense to backport this code fix to all old versions. We are expecting fix from reporting module.

[d_gosbell · Accepted solution]

---

@SagarSalvi wrote:

 We are expecting fix from reporting module.

 

---

Then you really need to log an official support ticket.

I did a quick test with HttpUtility.UrlEncode and UrlDecode and I can confirm that the encode does use + to encode spaces and the decode works correctly with this so to me it does look like a bug of some sort. But only Microsoft support could confirm if this is a bug or a specific design decision.

I can tell you that 2 possible work arounds are to either use %20 for space encoding or to use the /reportserver endpoint instead of the /reports one, but if you want Microsoft to consider a code fix on their side a support ticket is the best approach.

[SagarSalvi]

Yes we have a ticket with MSFT for this issue. We already met them once and demoed them the issue. They want their manager to review it. I will let you know once I have any concrete answer from them.

[d_gosbell]

I have not been using url parameters with + in them so I have not seen this. But have you tried using %20 instead? I think the + is a legacy encoding and the %20 is now the official standard, but I did a quick search and there appears to be others that are unsure which convention to use when.