The mappings are a combination of useless, inaccurate, and harmful.
Leave them out until they are helpful and correct.
Fundamental issues:
- If in need of mappings, a user would need HTTP -> gRPC code mappings.
But the docs don't provide that since the mappings are not 1:1.
- There _is no_ gRPC -> HTTP code mapping taking place in gRPC. This
may change in the future, but until then the docs are misleading.
But even given those were resolved, there are additional issues. Two
obvious examples:
- 501 Not Implemented is refering to HTTP methods such as GET and POST
not being implement. That should not be used for gRPC methods not
found (UNIMPLEMENTED).
- 404 Not Found is for when the resource is not found. In gRPC, the
resource is the gRPC method, not the parameters (NOT_FOUND). If there
is a REST conversion layer on top of gRPC, then 404 would be
appropriate, but that just shows that the mapping can not be
canonical.
- Renaming default credentials -> google default credentials.
- Various other things in cpp:
- Adding Cpp wrapping for JWT Tokens.
- Renaming ComposeCredentials -> CompositeCredentials.
- Tested with new tool (print_default_creds_token) on:
- workstation for env var and well known place.
- GCE for compute engine default creds.
- I'd prefer the grpc_default_credentials_create() API to remain
synchronous even though there may be an async call for gce detection
on which we block.
-) Let's not use _POSIX_SOURCE. It usually implies too much C99. _BSD_SOURCE would be the right thing to do here.
-) _BSD_SOURCE is getting deprecated by glibc, so we also have to define _DEFAULT_SOURCE under Linux.
-) accept4 and eventfd arn't as old as we may think; let's detect for it.
-) stdint.h interferes with all these definitions if included too early; let's move it down.