vault
                                
                                 vault copied to clipboard
                                
                                    vault copied to clipboard
                            
                            
                            
                        POST request with double forward slash and GET response
I send http request with double forward slash (post request)
(python3) url = "http://127.0.0.1:8200/v1/sys/mounts//kv"
payload = json.dumps({ "type": "kv" }) headers = { 'X-Vault-Token': 'root', 'X-Vault-Namespace': 'root', 'Content-Type': 'application/json' }
response = requests.request("POST", url, headers=headers, data=payload)
print(response.text)
I get info about mount kv: { "description": "", "seal_wrap": false, "external_entropy_access": false, "options": null, "type": "kv", "accessor": "kv_1cfd5e09", "local": false, "uuid": "06819bad-55c8-bb01-5640-13092614ba0d", "config": { "default_lease_ttl": 0, "force_no_cache": false, "max_lease_ttl": 0 }, "request_id": "0b82a6a5-10c6-ae51-b038-ec515a3564c0", "lease_id": "", "renewable": false, "lease_duration": 0, "data": { "accessor": "kv_1cfd5e09", "config": { "default_lease_ttl": 0, "force_no_cache": false, "max_lease_ttl": 0 }, "description": "", "external_entropy_access": false, "local": false, "options": null, "seal_wrap": false, "type": "kv", "uuid": "06819bad-55c8-bb01-5640-13092614ba0d" }, "wrap_info": null, "warnings": null, "auth": null }
Is this normal behavior ? I know It depends on serveMux https://github.com/hashicorp/vault/blob/56a10bb10f5e585415d8ad23aecd15a78a5048f3/http/handler.go#L127
I found this issue https://github.com/golang/go/issues/42244
Making an HTTP request with multiple consecutive slashes in the URL-path to the Vault API does not have a defined behaviour.
The actual behaviour is that Vault inherits the Go http library's default of responding with a 301 redirect to the path with the slashes deduplicated.
It appears that your client then resubmits a GET request to the redirect destination.
There is certainly an argument here that the inherited default behaviour from the Go library is not ideal - but ultimately the issue can be avoided by not making a questionably-valid request in the first place.