Forward invocation HTTP headers to target service#4720
Conversation
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
|
I have read the CLA Document and I hereby sign the CLA Yi Pan seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account. |
- Extract headers from Input journal entry during invocation setup - Pass headers through to prepare_request function - Add invocation headers to HTTP request sent to target service - Filter protocol-reserved headers to prevent conflicts - Log warnings for invalid headers and drop them gracefully - Support both service protocol V4 and legacy V1-V3 - Support both JournalV1 and JournalV2 storage formats - Comprehensive unit tests with 13 test cases This enables headers from HTTP ingress and service-to-service calls to be forwarded to the target service endpoint. When a service is invoked (either via HTTP ingress or via service_call from another service), the headers included in the invocation request are now forwarded as HTTP headers to the target service's HTTP endpoint. Technical details: - Reads Input entry (index 0) from journal to extract headers - Converts restate_types::invocation::Header to http::HeaderValue - Skips protocol headers (content-type, accept, x-restate-invocation-id, traceparent, tracestate) to avoid conflicts - Logs WARN for invalid header names/values before dropping them - Gracefully handles missing/failed header reads (uses empty list) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
nickpan47
force-pushed
the
feature/forward-invocation-headers
branch
from
6b7d130 to
5e12fd1
Compare
|
I have read the CLA Document and I hereby sign the CLA |
|
Thanks a lot for creating this PR @nickpan47. We are currently in the process of finalizing the v1.7 release and that's why our response time might be a bit slower. Sorry for that. In the meantime, could you help me understand a bit better why you would like to send the invocation headers as HTTP headers of the physical request from the Restate server to the service endpoint? I am assuming that those headers carry some form of auth information that the infra needs to see to let the Restate invocation go through to the service endpoint. Is this auth information provided by the caller of the invocation so that the Restate server cannot obtain it itself? |
Hey, Till, thanks for the quick response. The key reason for this pr is to satisfy our production security model: our security model requires the receiving service to identify the original entity that sends the request, not blindly trust the proxy (i.e. in this case, Restate). Hence, the original caller's service identity has to be carried over to the downstream service that receives this call. In addition to that, we use envoy as the service mesh layer to forward the requests, intercept the headers info and apply auth/authz based on the headers. Thus, the original caller's service identity has to be part of the envoy visible headers to make it work. Hope that explains it. |
|
Thanks for the clarification @nickpan47. We are going to look into this problem and your PR. |
2 participants
This enables headers from HTTP ingress and service-to-service calls to be forwarded to the target service endpoint.
When a service is invoked (either via HTTP ingress or via service_call from another service), the headers included in the invocation request are now forwarded as HTTP headers to the target service's HTTP endpoint.
Technical details:
I have read the CLA Document and I hereby sign the CLA