When the params query contains the # symbol, the system ignores this symbol and everything after it, resulting in issues with the query results

[yukicoding]

I have checked the following:

• I use the newest version of bruno.
• I've searched existing issues and found nothing related to my issue.

Describe the bug

1. Issue Description:
When the params query contains the # symbol, the system ignores this symbol and everything after it, resulting in issues with the query results.
2. Expected Behavior:
The # symbol and everything after it in the query should be processed correctly, instead of being treated as a comment and ignored.
3. Steps to Reproduce:
Include the # symbol and its subsequent content in the query.
Run the query and observe the results.
Notice if the query results are missing the content after the # symbol.
4. Actual Behavior:
The content after the # symbol is ignored in the query results, leading to incomplete or incorrect results.
5. Environment Information:
Operating System: Windows

.bru file to reproduce the bug

ListNgsStepsV2.zip

Screenshots/Live demo link

This one's from bruno.

This one's from other app.

[Its-treason]

I think that the # and everything after is not sent, is expected behavior, see: https://blog.httpwatch.com/2011/03/01/6-things-you-should-know-about-fragment-urls/

You could change the # to the URL-Encodes equivalent → %23. But Bruno does not do encode the URL by default.

We should definitely update the query parameter parser to handle #, so it's more obvious where the URL fragment begins.

[AndreKR]

Bruno does not do encode the URL by default

This is the actual issue here. If there is a table where you enter parameters and the platform converts them into a query string (concatenates them with ? and &) the platform should also encode the parameters before concatenating. Everything else would be wrong and unexpected in my book.

[pietrygamat]

On the same note: #2124.
The problem to keep in mind here is that the conversions from query params in the URL field should automatically update the table and at the same time the updates in the table should automatically update the URL field.
Does that mean the table should ALWAYS contain non-url encoded values (or if they are provided url encoded, they get double encoded on send)?
What about the equals sign typed as value into the URL field, as reported in linked issue?
E.g.: https://example.com/search?filter=color=red
is a url with query param filter having value of color=red . If I type it into url field, it's not wrong, and the table will be updated accordingly (or should be, because the bug is there atm). Then, assuming the updates on in the table should automatically url-encode query param values in the URL field, any change to params table will change value in URL field from:
https://example.com/search?filter=color=red to https://example.com/search?filter=color%3Dred, which seems undesired as well, right?