Insomnia: [Feature] Configurable URL Encoding

[gschier]

Related to #592 and #604

Problem Description

From day 1, Insomnia has always automatically encoded path and query segments in the URL. The initial reason for this was to preserve compatibility with the legacy version of Insomnia (Chrome App) where the URLs were automatically encoded by the Chrome network layer.

For a lot of users, this auto-encoding causes problems and the severity is amplified by the fact that it is actually impossible to send non-encoded special characters.

Potential Solutions

There are a number of ways this can be solved. Please let me know which one you think is best:

• Disable automatic encoding completely (likely too disruptive of a change)
  
  
  
  • In this scenario, there could be a Template Tag for encoding values explicitly
  
  
• Add option on each query parameter to enable/disable encoding
• Add global workspace-level setting to enable/disable encoding
• Have a character whitelist for encoding (would solve 90% of problems)

[oliverjanik]

Coming from #604.

I don't thing this should be an option. If it is it the default for encoding should be 100% standard compliant.

If you follow RFC 100% and not encode anything extra for no reason, that would cover my use-case of messed up query string.

As an API developer tool Insomnia should strive to be 100% standard compliant and do exactly as I tell it too (as a developer) any magic that happens without my knowledge is not acceptable.

As a side note, I was too quick to point out that Postman works (Chrome version did). I filed this bug yesterday: https://github.com/postmanlabs/postman-app-support/issues/3816

Same problem really just picks different characters to encode 🤷‍♂️

[gschier]

I totally agree that Insomnia should follow the standard as closely as possible. However, the unfortunate reality is that changing the default would break the application for too many users. There must be a way to preserve the current behavior for all existing users of the app. An option would satisfy this requirement.

After thinking about this for a while, I have a few more thoughts.

Having an option configurable at the workspace-level could allow the app to set auto-encoding "on" for existing workspaces and "off" for new ones. This would mean that all new users would not experience auto-encoding by default. And, it would also mean that workspaces shared via the export and sync would preserve the auto-encoding behavior from where they were exported.

[pimterry]

I'd prefer going to standards-based behaviour too, and that option (set for old projects, unset for new) sounds like a sensible migration path to me.

I imagine the per-parameter on/off setting would be a nice option in cases where I did need to think about intentionally encoding characters further. It's hard to judge if anybody actively needs that right now, mainly because it's currently the default, but if that is a substantial use case then that sounds like nice UX for it imo.

[charlex]

I'd like to chime in and voice my support for the ability to turn on and off encoding for query parameters. Elastic search query strings require colons to be passed in unencoded, so the query editor in Insomnia is rendered fairly unusable for that usecase. I recognize this is just one example, but I think there are perhaps many users of Elastic search's querystring feature that could also benefit from Insomnia's query editor.

[oliverjanik]

I think it's important to recognise that query parameters are not part of URI standard: https://tools.ietf.org/html/rfc3986

Although query name value pairs are common, they are not mandated by this standard (this is my use case, I don't use name value pairs and strange things happen in Insomnia).

The name value pairs actually come from HTML standard for form encoding: https://www.w3.org/TR/html401/interact/forms.html#form-content-type
Which what browser does when you have a <form method="GET">

The following is the behaviour I'd prefer:

1) By all means encode params in the query params builder, even have it on off if that's a requested feature.
2) Once I type something into the address bar, no magic should happen, no surprising behaviour. Do not try and interpret my query string. What I type in should be on the wire, provided that it's valid.

[jaldinger]

+1 for this feature request... 👍

[jperezlatimes]

+1 for adding an encoding on/off switch in the query params builder.

I have the same use case as @charlex , working with elasticsearch URI strings is not possible when Insomnia automatically encodes everything.

https://www.elastic.co/guide/en/elasticsearch/reference/current/search-uri-request.html#search-uri-request

[osamakhn]

+1 to the above query; I need to pass soql query as query param delimited by + but it gets encoded

[roblav96]

Disable Request URL Encoding

No idea why this isn't documented anywhere 😕

@osamakhn @jaldinger @jperezlatimes @oliverjanik @gschier

[osamakhn]

Thanks @roblav96 !

[maurilax]

While this is great, that option specifically leaves out the ability to not encode query string parameters. In my case I have a query parameter that takes a string for a SELECT statement with + instead of spaces. The + are getting encoded and breaking the query.

[gschier]

Correct, it does not apply to anything placed inside the Query tab.

I actually don't even remember why I added that option, as it doesn't seem very useful looking at it now.

[roblav96]

@gschier Thoughts on this preferance being placed in workspace settings?

So far out of the 6 months I've been using Insomnia daily, this is the first con so not to worry, it's still by far the best rest api client to date! Keep up the amazing work! =]

[khandelwalbrijesh]

Thanks for the feature, but I was working on a Rest API which had query parameters like "A+B+C". In Insomnia, the auto encoding option is "On" by default. So, when I tested the API using Insomnia it converted "+" to "%2B" and my rest APIs worked correctly in the way i wanted them to. But all the others tools don't encode "+" and there it is failing. Now, I might have to restructure my API or change the encoding of the requests received.
My point is that the Option for automatic encoding should be disabled in Insomnia by default. Insomnia should be behave like other tools in default state.

[oliverjanik]

Can we have this Off for any new request? It's absolutely crazy to have non-standard behaviour as default.

[putuyoga]

Correct, it does not apply to anything placed inside the Query tab.

Is there any workaround to turn off the url-encoding on Query tab?

[ian-schu]

+1 for disabling automatic encoding of query params. I'm working with a somewhat-awkward real estate API, where we need to send params that are literally (e.g.): &$filter=contains(StreetName,'Main Street')

^ Right now this can't be done in Insomnia (or so far as I can tell).

[ogrim]

@ian-schu OData, how I don't miss it! 😅

I am using Insomnia to poke at external APIs I am integrating with, so it is just plain wrong to force Insomnia to be 100% standards compliant. There are a lot of shitty APIs out there doing non-standard things, I still need to create integrations against them :) For creating an API yourself, I agree - then you want strict validation of everything to ensure correctness. I probably have to drop down to curl for testing some shitty APIs, would much prefer to use Insomnia instead!

[Chillifish]

Another vote for disabling encoding of query parameters. I'm trying to debug an API with a search parameter that won't accept encoding.

[kurbar]

Since the issue here is still open - It would be awesome if we are able to URL encode/decode tag values as well.

I have a use case where I get an encrypted and base64 encoded XSRF token as a cookie. In cases where the base64 string is padded with =, then the cookie has them urlencoded. But now I cannot decode it for the X-XSRF-Token header. At least not on Mac