New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a section on Response rewriting to Application Gateway details #15750
Add a section on Response rewriting to Application Gateway details #15750
Conversation
✅ 🥰 Documentation preview ready! 🥰
To edit notification comments on pull requests, go to your Netlify site settings. |
docs/05-technical-reference/ac-01-application-gateway-details.md
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would also suggest adding some basic information to the user-facing Application Gateway doc. Something along these lines:
Application Gateway supports redirects for the request flows in which the URL host remains unchanged.
Co-authored-by: Jan Mędrek <jan.medrek@sap.com>
15f9892
to
f597be2
Compare
|
||
## Response rewriting | ||
|
||
If during a call to the external system, the target responds with a redirect (`3xx` status code) that points to the URL with the same host and a different path, the `Location` header is modified so that the original target path is replaced with the Application Gateway URL and port, with the sub-path pointing to the called service attached at the end, in this format: `{APP_GATEWAY_URL}:{APP_GATEWAY_PORT}/{APP_NAME}/{SERVICE_NAME}/{SUB-PATH}`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If during a call to the external system, the target responds with a redirect (`3xx` status code) that points to the URL with the same host and a different path, the `Location` header is modified so that the original target path is replaced with the Application Gateway URL and port, with the sub-path pointing to the called service attached at the end, in this format: `{APP_GATEWAY_URL}:{APP_GATEWAY_PORT}/{APP_NAME}/{SERVICE_NAME}/{SUB-PATH}`. | |
If during a call to the external system, the target responds with a redirect (`3xx` status code) that points to the URL with the same host and a different path, the `Location` header is modified so that the original target path is replaced with the Application Gateway URL and port. The sub-path points to the called service attached at the end, in this format: `{APP_GATEWAY_URL}:{APP_GATEWAY_PORT}/{APP_NAME}/{SERVICE_NAME}/{SUB-PATH}`. |
I'd split this long sentence :D
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It can't be split this way, because that's not what it means, but you drew my attention to its ambiguity!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's the sub-path that's attached and it's important to have it all in once sentence, even though I also hate that it's long :(
|
||
If during a call to the external system, the target responds with a redirect (`3xx` status code) that points to the URL with the same host and a different path, the `Location` header is modified so that the original target path is replaced with the Application Gateway URL and port, with the sub-path pointing to the called service attached at the end, in this format: `{APP_GATEWAY_URL}:{APP_GATEWAY_PORT}/{APP_NAME}/{SERVICE_NAME}/{SUB-PATH}`. | ||
|
||
This functionality makes the HTTP clients that originally called Application Gateway follow redirects through the Gateway, and not to the service directly. This allows for passing authorization, custom headers, URL parameters, and the body without an issue. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This functionality makes the HTTP clients that originally called Application Gateway follow redirects through the Gateway, and not to the service directly. This allows for passing authorization, custom headers, URL parameters, and the body without an issue. | |
This functionality makes the HTTP clients that originally called Application Gateway follow redirects through the Gateway, and not to the service directly. This allows for passing authorization, custom headers, URL parameters, and the body. |
I'd drop the without an issue
part. It sounds like sth could go wrong. We don't want that :D
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It could go wrong if there is no response rewriting.
Description
Add a section on Response rewriting to Application Gateway details.
Changes proposed in this pull request:
Related issue(s)
#14717