Insomnia: First '%' in POST data isn't urlencoded, if post data has '%' multiple.

[Ippey]

• Insomnia Version: Version 6.2.3 (6.2.3.2532)
• Operating System: MacOS Mojave

Details

First '%' in POST data isn't urlencoded, if post data has '%' multiple.
I tried bellow.

POST http://www.example.com/api
Structured: Form URL Encoded
request data : arg=abc%def%ghi%jkl

Then I checked Timeline, POST data is bellow,
> POST /api HTTP/1.1
> Host: www.example.com
> User-Agent: insomnia/6.2.3
> Content-Type: application/x-www-form-urlencoded
> Accept: */*
> Content-Length: 23
| arg=abc%def%25ghi%25jkl

Post data became 'arg=abc%def%25ghi%25jkl'.
I think 'arg=abc%25def%25ghi%25jkl' is collect.
Although "Generate Code" is OK.

curl --request POST \
  --url http://www.example.com/api \
  --header 'content-type: application/x-www-form-urlencoded' \
  --cookie PHPSESSID=session_id \
  --data arg=abc%25def%25ghi%25jkl

Thank you.

[welcome[bot]]

👋 Thanks for opening your first issue! If you're reporting a 🐞 bug, please make sure
you include steps to reproduce it. If you're requesting a feature 🎁, please provide real
use cases that would benefit. 👪

To help make this a smooth process, please be sure you have first read the
contributing guidelines.

[AL1L]

Maybe because %DE is a valid encoding of a character (Þ) while %GH and %JK are not

[BehindTheMath]

This can be reproduced even more simply. A value of %11 will not be encoded at all, and will be sent as is.

curl --request POST \
  --url http://httpbin.org/post \
  --header 'content-type: application/x-www-form-urlencoded' \
  --data test=%2511

> POST /post HTTP/1.1
> Host: httpbin.org
> User-Agent: insomnia/6.4.1
> Content-Type: application/x-www-form-urlencoded
> Accept: */*
> Content-Length: 8

| test=%11

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[BehindTheMath]

This is still an issue.

CC @gschier

[BehindTheMath]

After some research, it looks like the issue being caused by this code. Any raw text that matches an already-encoded character is ignored, so %11 will never be encoded.

[AL1L]

Not really sure how to interpret this, but RFC 3986 Section 2.4 outlines when to encode or not. I think that if the percent-encoding is invalid, such as the %jk above then the % must be encoded (into %25) as it is scheme-specific while %de is a valid encoding.

So if something is wrong, then is it the way the code generator does it?

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[BehindTheMath]

This is still an issue.

@gschier Is there any way to stop this from being marked as stale?

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[BehindTheMath]

@gschier This hasn't changed. Are we going to go through this every 2 months?

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[BehindTheMath]

@gschier This hasn't changed. Are we going to go through this every 2 months?

I guess we are.

[gschier]

Sorry about that. Won't be marked stale now.