Closed weichch closed 3 years ago
That makes sense, but it's going to require some design changes. Most transforms use the return of an empty value to indicate the header, query param, etc, should be removed. You're right that an empty query param is valid, though I don't know how common it is to require its presence. We'll have to re-think how transforms indicate removal.
Triage: Distinguish between empty string and null? Given that it affects design, we should do it in 1.0.
@Tratcher I agree it's not commonly seen but unfortunately our destination server uses the key of the parameter instead of the value, and it doesn't allow any value set. I was thinking a new property AllowEmptyValue
which defaults to false
, then I can explicitly set it to true
when needed. Similar to OpenAPI specs:
Empty-Valued and Nullable Parameters Query string parameters may only have a name and no value, like so: GET /foo?metadata Use allowEmptyValue to describe such parameters:
Describe the bug
I'm proxying request from
http://source/path
tohttp://destination/path?param1=¶m2=value
, with two transforms:However,
param1
is dropped while being applied toRequestParametersTransformContext
due to this line of code.Empty string is valid variable value as per RFC 6570 and in my case the destination server cannot work without
param1
.To Reproduce
Further technical details