reverse-proxy
reverse-proxy copied to clipboard
microsoft
Make Exists Mode for QueryParameters support empty parameters
Discussed in https://github.com/microsoft/reverse-proxy/discussions/2553
Originally posted by ppv-milestone July 17, 2024 We need to match queries to an interface that accepts a request like this: http://path/component?hello But according to documentation the "Exists" Mode in QueryParameters will only match against non-empty parameters and our tests show that Prefix, Exact and Contains seem to be following the same (providing "" as a value to match for causes the service to fail). Also tried with regular expressions in Path, but those does not seem to match on parameters. Anyone has a workaround for this? Or maybe supporting empty parameters for Exists could be supported in next version? Thanks a lot in advance! Br, Peter
FWIW the query parameters here is matching what we do for headers: https://github.com/microsoft/reverse-proxy/blob/b1a1d8b20a2ff599517705771ce87614799e8ceb/src/ReverseProxy/Routing/HeaderMatcherPolicy.cs#L78-L83 https://github.com/microsoft/reverse-proxy/blob/b1a1d8b20a2ff599517705771ce87614799e8ceb/src/ReverseProxy/Routing/QueryParameterMatcherPolicy.cs#L77-L81
and the behavior was intentional for headers at least. I'd find it surprising if the two were inconsistent.
FWIW the query parameters here is matching what we do for headers:
https://github.com/microsoft/reverse-proxy/blob/b1a1d8b20a2ff599517705771ce87614799e8ceb/src/ReverseProxy/Routing/HeaderMatcherPolicy.cs#L78-L83
https://github.com/microsoft/reverse-proxy/blob/b1a1d8b20a2ff599517705771ce87614799e8ceb/src/ReverseProxy/Routing/QueryParameterMatcherPolicy.cs#L77-L81
and the behavior was intentional for headers at least. I'd find it surprising if the two were inconsistent.
Why do you assume the behavior was intentional for headers and not just the easiest approach? To me it sounds a bit counter-intuitive that Exists goes on whether it has a value instead of whether it actually is present or not - both for headers and query parameters.
It was intentional for headers. Empty headers have no semantic meaning and may be dropped by intermediaries.
The query situation is a bit different. We assume key-value pairs (?key1=a&key2=b), but having a single key without an equals sign is still meaningful (?key1&key2). AspNetCore isn't great at representing this case, it doesn't distinguish between key1= and key1.
