Forum Discussion
Helper IJanuary 2022 PBI RS: Parameter values from query string are not properly decoded in RDL report
Example:
https://reportserver/reports/report/Customerfolder/TestReport?ConnectionString=server%3dSQLServerName%3b+initial+catalog%3dTESTDB&rc:Parameters=Collapsed&rs:Embed=true&rc:Zoom=100
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?
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.
Wanted to reply that this has been fixed and will be released in the May release of Power BI Report Server.
Thought to update this post. This issue is fixed by MSFT in PBI RS September 2022.
11 Replies
PetebroMicrosoft Employee
Wanted to reply that this has been fixed and will be released in the May release of Power BI Report Server.
SagarSalviYes, 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.
- 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.
- d_gosbell
Super User
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.
- 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
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.
- v-henryk-mstf
Community Support
Hi SagarSalvi ,
Please let me know if there are any further updates. Looking forward to your feedback.
Best Regards,
Henry