You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Headers field names are case-insensitive as per RFC7230, but they're being treated as case-sensitive in requests.
The root of the problem seems to be that in oas3/parameterParsers/index.ts, many parameters go through the toStructuredParser function, that does const value = rawParamValues[location.name]. rawParamValues has the header keys already in lower-case, while location.name is still in Train-Case.
I've got a PR to fix this in the works, though I'm not sure if the way I solved this was the best approach possible. I copied the one used for query parameters -- to call a different function in oas3/Operation.ts in parseParameters for them and, do a little preprocessing -- but it feels a little redundant to do this for each location (i.e. in: query / in: header), when we already have custom parsers that vary by style / format.
The text was updated successfully, but these errors were encountered:
brocoli
changed the title
Parameters with in: header are not being handled as case-insensitive
Header parameters are not being handled as case-insensitive
Feb 4, 2019
brocoli
pushed a commit
to brocoli/exegesis
that referenced
this issue
Feb 4, 2019
Header name fields were not being handled as case-insensitive,
which would cause unwanted authentication and validation errors.
Refer RFC7230.
Fixesexegesis-js#75
Headers field names are case-insensitive as per RFC7230, but they're being treated as case-sensitive in requests.
The root of the problem seems to be that in
oas3/parameterParsers/index.ts
, many parameters go through thetoStructuredParser
function, that doesconst value = rawParamValues[location.name]
.rawParamValues
has the header keys already in lower-case, whilelocation.name
is still in Train-Case.I've got a PR to fix this in the works, though I'm not sure if the way I solved this was the best approach possible. I copied the one used for query parameters -- to call a different function in
oas3/Operation.ts
inparseParameters
for them and, do a little preprocessing -- but it feels a little redundant to do this for each location (i.e. in: query / in: header), when we already have custom parsers that vary by style / format.The text was updated successfully, but these errors were encountered: