#Http decode free

agent/health_endpoint.go ( URL-encode/decode resource names for HTTP API part 3 #12103) agent/federation_state_endpoint.go ( URL-encode/decode resource names for HTTP API part 3 #12103)

agent/event_endpoint.go ( URL-encode/decode resource names for HTTP API part 3 #12103) agent/discovery_chain_endpoint.go ( URL-encode/decode resource names for HTTP API part 2 #11957) agent/coordinate_endpoint.go ( URL-encode/decode resource names for HTTP API part 2 #11957) agent/connect_ca_endpoint.go (no affected endpoints) agent/config_endpoint.go ( URL-encode/decode resource names for HTTP API part 2 #11957) agent/catalog_endpoint.go ( URL-encode/decode resource names for HTTP API part 2 #11957) agent/agent_endpoint.go ( URL-encode/decode resource names for HTTP API #11335) agent/acl_endpoint.go ( URL-encode/decode resource names for HTTP API part 2 #11957)

#Http decode free

Since the number of modified files is expected to be large, you are welcome to start work on a subset of endpoints and ask for feedback on your proposed solution/pattern before applying it to more places.įeel free to ask any questions and a member of our team will respond. This has been proven wrong in #12184 - we only need to add decoding on handlers. We previously assumed we also had to URL-encode corresponding HTTP calls in api module. We should URL-decode path arguments when HTTP handlers try to parse the resource name ( example can find others by searching for strings.TrimPrefix()

However, our handlers naively parse the URL as-is without a decode step, making it impossible to interact with resources that may have URL unsafe characters in their name or ID. Since some resource names are not URL safe, the caller must URL-encode certain characters. Consul CLI has many commands that make HTTP calls to the local agent's HTTP API.