Bug fix: Make get_route_info() case insensitive #60
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR makes
TGISBackend.get_route_info()
's operation case insensitive.Both gRPC and HTTP defines their metadatum/headers as case insensitive. This requires any lookup of keys to be done in a case insensitive manner.
Additionally fixed the
test_get_route_info
test:TestServicerContext
to inherit fromgrpc.ServicesContext
. This was required becauseTGISBackend.get_route_info()
test if the servicer context is ofgrpc.ServicerContext
before attempting to access the metadata.latin-1
as per http spec and what starlette expects.Note:
Depending on how the
fastapi.Request
object (actually a starlette.requests.Request object) is created, it might not instantiate its headers in a case insensitive manner. If thestarlette.datastructures.Headers
is created via thescope=
parameter the header keys still remain case sensitive. This is whyHeaders.get()
is not reliable and a customTGISBackend._request_header_get()
was necessary.