Fix Location header to respect X-Forwarded-Proto and X-Forwarded-Host headers #3095
+14
−8
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.
Why make this change?
POST to stored procedure/entity endpoints returns Location header with
http://scheme even when original request is HTTPS. This occurs behind reverse proxies (Azure API Management, Container Apps) where internal traffic uses HTTP but theX-Forwarded-Proto: httpsheader is set.What is this change?
Reuses existing
SqlPaginationUtil.ResolveRequestSchemeandResolveRequestHosthelpers (already used for paginationnextLink) in mutation handlers:private→internalforResolveRequestScheme,ResolveRequestHost,IsValidScheme,IsValidHostBefore:
After:
How was this tested?
Existing validation logic from pagination already handles header validation (scheme must be
http/https, host validated for dangerous characters).Sample Request(s)
Response now correctly includes:
Original prompt
This section details on the original issue you should resolve
<issue_title>[Bug]: POST to rest endpoint on https for stored proc returns a location header with insecure http scheme</issue_title>
<issue_description>### What happened?
A bug happened!
Posting to a stored procedure endpoint returns a location header that doesn't match the request incoming scheme. This results in errors on clients that don't allow insecure redirects.
The returned scheme should match the incoming scheme
Version
1.6.84
What database are you using?
Azure SQL
What hosting model are you using?
Container Apps
Which API approach are you accessing DAB through?
REST
Relevant log output
Code of Conduct
<agent_instructions>Resolve this bug with as little code change as possible.</agent_instructions>
Comments on the Issue (you are @copilot in this section)
@JerryNixon ## Root CauseThe issue is in how DAB constructs the
Locationheader for stored procedure POST requests. When building the location header URL, DAB is not properly respecting the incoming request's HTTPS scheme when behind a reverse proxy.The Problem Code
Looking at
SqlMutationEngine.csfor stored procedure handling:The problem is that
httpContext.Request.Schemereturns the scheme of the connection between the reverse proxy (Azure API Management) and the container app (HTTP), not the original client request scheme (HTTPS).Why Regular Entity Inserts Work Better
Interestingly, for regular table/view POST operations, DAB uses
SqlResponseHelpers.ConstructCreatedResultResponse(), which has the same issue:The Solution That Exists for Pagination
DAB already has the correct implementation for handling forwarded headers in the pagination utility (
SqlPaginationUtil.cs):The helper methods check for
X-Forwarded-ProtoandX-Forwarded-Hostheaders: