consul

consul copied to clipboard

Overview of the Issue

A "Non-breaking space" (U+00A0) in the key name throws an error in v1.12.3. The "classic" withe space (U+0020) works well.

In v0.8.3 this character could have been used, so now we are dealing with cases where keys have been created with this special char, an export was made and when importing such export we hit the below Unexpected response code: 400 error.

Reproduction Steps

To reproduce, try to create a new key with value consul kv put "keyName WithNBSP", which contains the "Non-breaking space" (U+00A0) in the key:

v1.12.3:

[[email protected] /]$ consul -v
Consul v1.12.3
[[email protected] /]$ consul kv put "keyName WithWhitespace"
Success! Data written to: keyName WithWhitespace
[[email protected] /]$ consul kv put "keyName WithNBSP"
Error! Failed writing data: Unexpected response code: 400 ()
[[email protected] /]$

v0.8.3

[consul@consul-debug /]$ consul -v
Consul v0.8.3
[consul@consul-debug /]$  consul kv put "keyName WithWhitespace"
Success! Data written to: keyName WithWhitespace
[consul@consul-debug /]$ consul kv put "keyName WithNBSP"
Success! Data written to: keyName WithNBSP
[consul@consul-debug /]$ consul kv get "keyName WithNBSP"

[consul@consul-debug /]$

Consul info for Server

agent:
	check_monitors = 0
	check_ttls = 0
	checks = 0
	services = 0
build:
	prerelease =
	revision = 2308c75e
	version = 1.12.3
	version_metadata =
consul:
	acl = disabled
	bootstrap = false
	known_datacenters = 1
	leader = true
	leader_addr = 127.0.0.1:8300
	server = true
raft:
	applied_index = 29013
	commit_index = 29013
	fsm_pending = 0
	last_contact = 0
	last_log_index = 29013
	last_log_term = 2
	last_snapshot_index = 18213
	last_snapshot_term = 2
	latest_configuration = [{Suffrage:Voter ID:fd361b64-671b-dfc5-00b4-1ffdce47ce8d Address:127.0.0.1:8300}]
	latest_configuration_index = 0
	num_peers = 0
	protocol_version = 3
	protocol_version_max = 3
	protocol_version_min = 0
	snapshot_version_max = 1
	snapshot_version_min = 0
	state = Leader
	term = 2
runtime:
	arch = amd64
	cpu_count = 8
	goroutines = 106
	max_procs = 8
	os = linux
	version = go1.18.1
serf_lan:
	coordinate_resets = 0
	encrypted = false
	event_queue = 1
	event_time = 2
	failed = 0
	health_score = 0
	intent_queue = 0
	left = 0
	member_time = 1
	members = 1
	query_queue = 0
	query_time = 1
serf_wan:
	coordinate_resets = 0
	encrypted = false
	event_queue = 0
	event_time = 1
	failed = 0
	health_score = 0
	intent_queue = 0
	left = 0
	member_time = 1
	members = 1
	query_queue = 0
	query_time = 1```

</details>

### Operating system and Environment details

OS, Architecture, and any other information you can provide about the environment.

### Log Fragments

Include appropriate Client or Server log fragments. If the log is longer than a few dozen lines, please include the URL to the [gist](https://gist.github.com/) of the log instead of posting it in the issue. Use `-log-level=TRACE` on the client and server to capture the maximum log detail.

### Operating system and Environment details

"Red Hat Enterprise Linux 8.6 (Ootpa)"

Jul 21 '22 14:07 Lupotslboy

Hey @Lupotslboy

Thanks for reporting this bug. We'll look into this and see what's going on here. It's possible that this change could've been intentional for one reason or another but i'm not sure on first glance.

Jul 22 '22 16:07 Amier3

Hi @Lupotslboy,

As of Consul 1.12.0, the CLI will automatically URL-encode parameters provided via the CLI when passing to the HTTP API. I'm wondering if that's related to what you're seeing. These questions might help identify whether that's related:

• What happens if you use the key read/write HTTP API endpoints directly instead of the CLI?
• Do you see the same behavior on latest 1.11.x (instead of 1.12.x)?

Jul 22 '22 22:07 jkirschner-hashicorp

Hey Jared,

trying 1.12.3 from the web ui I hit a 400 error (shown in the web UI and in the network request as per image).

If I try the curl request of the same (using the url encoding captured from web request) I do not get any return message/error.

[consul@consul-debug-new /]$ curl 'http://10.10.171.135:8700/v1/kv/keyName%C2%A0WithNBSP?dc=dc1' \
>   -X 'PUT' \
>   -H 'Accept: */*' \
>   -H 'Accept-Language: en-US,en;q=0.9,it;q=0.8' \
>   -H 'Connection: keep-alive' \
>   -H 'Content-Type: application/json; charset=UTF-8' \
>   -H 'X-Requested-With: XMLHttpRequest' \
>   --data-raw 'value' \
>   --compressed \
>   --insecure ;
[consul@consul-debug-new /]

although the key is not getting created:

[consul@consul-debug-new /]$ curl 'http://10.10.171.135:8700/v1/kv/?keys&dc=dc1&separator=%2F' \
> -H 'Accept: */*' \
> -H 'Accept-Language: en-US,en;q=0.9,it;q=0.8' \
> -H 'Connection: keep-alive' \
> -H 'Content-Type: application/json; charset=utf-8' \
> -H 'X-Requested-With: XMLHttpRequest' \
> --compressed \
> --insecure
[]
[consul@consul-debug-new /]$

With v 1.11.0 things are slightly different: I can create a key with a regular space in the name, both in the web ui and using the cli, but when I use the web ui I can't see the same key (created with a blank in the web ui) from cli and vice versa.

Using a NBSP I get the 400 error (and seems is enconding as in 1.12.3) from web UI and from cli.

Jul 25 '22 09:07 Lupotslboy