Skip to content
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

Grammar + typo fix #1004

Merged
merged 2 commits into from
Oct 27, 2023
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
---
title: "Modifying HTTP Response Headers"
author: ruslany
description: "This section of the documentation applies to the URL Rewrite Module Version 2.0 for IIS 7. This walkthrough will guide you through how to use URL Rewrite Mo..."
description: "This walkthrough guides you through how to use URL Rewrite Module Version 2.0 for IIS 7."
ms.date: 11/06/2009
ms.assetid: 132a56b5-7308-4c9a-ba67-e9550783bd52
msc.legacyurl: /learn/extensions/url-rewrite-module/modifying-http-response-headers
Expand All @@ -13,7 +13,7 @@ by [Ruslan Yakushev](https://github.com/ruslany)

This section of the documentation applies to the **URL Rewrite Module Version 2.0 for IIS 7**.

This walkthrough will guide you through how to use URL Rewrite Module v 2.0 to set HTTP response headers.
This walkthrough guides you through how to use URL Rewrite Module v 2.0 to set HTTP response headers.

## Prerequisites

Expand All @@ -25,20 +25,20 @@ This walkthrough requires the following prerequisites:

## Introduction

URL Rewrite Module 2.0 provides support for rules-based rewriting of the response HTTP headers. A very common usage scenario for setting the response headers is to modify the redirection response generated by an application behind a load balancer or a reverse proxy. For example when an application behind a reverse proxy returns a redirect response, the HTTP Location header in the response may not represent the internet-facing address, but rather an internal application address. URL Rewrite Module 2.0 can be used on the reverse proxy server to modify the Location header in the response. The scenario is represented on the following diagram:
URL Rewrite Module 2.0 provides support for rules-based rewriting of the response HTTP headers. A very common usage scenario for setting the response headers is to modify the redirection response generated by an application behind a load balancer or a reverse proxy. For example, when an application behind a reverse proxy returns a redirect response, the HTTP Location header in the response may not represent the internet-facing address, but rather an internal application address. URL Rewrite Module 2.0 can be used on the reverse proxy server to modify the Location header in the response. The scenario is represented on the following diagram:

![Diagram that shows the redirect response process among the client, reverse proxy server, and the internal client server.](modifying-http-response-headers/_static/image1.png)

1. An HTTP client makes a request to a web page `http://www.contoso.com/webmail/oldpage.aspx`.
2. The reverse proxy server uses URL Rewrite 2.0 and Application Request Routing to forward the request to an internal content server based on the name of the folder in the requested URL path, e.g. `http://webmail/oldpage.aspx`;
2. The reverse proxy server uses URL Rewrite 2.0 and Application Request Routing to forward the request to an internal content server based on the name of the folder in the requested URL path. For example, `http://webmail/oldpage.aspx`;
3. The web application that is running on the content server issues a redirect response (HTTP/1.1 301) pointing an HTTP client to `http://webmail/newpage.aspx`;
4. The reverse proxy server uses URL Rewrite 2.0 to replace the internal-based redirection location in the response with the internet-based redirection location: `http://www.contoso.com/webmail/newpage.aspx`.

## Setting up a walkthrough scenario

To setup the walkthrough scenario complete the walkthrough about [Reverse Proxy with URL Rewrite v2 and Application Request Routing](reverse-proxy-with-url-rewrite-v2-and-application-request-routing.md). At the end of that walkthrough you should have a reverse proxy web site that routes requests to two content applications: webmail and payroll.
To set up the walkthrough scenario, complete the walkthrough about [Reverse Proxy with URL Rewrite v2 and Application Request Routing](reverse-proxy-with-url-rewrite-v2-and-application-request-routing.md). At the end of that walkthrough, you should have a reverse proxy web site that routes requests to two content applications: webmail and payroll.

For this walkthrough you will need to add a redirection logic to the webmail application. In real-life scenario that would probably be a redirection initiated by the web application code, but, for simplicity, in this walkthrough you will use a redirect rule in URL Rewrite Module.
For this walkthrough, you'll need to add a redirection logic to the webmail application. In real-life scenario, that would probably be a redirection initiated by the web application code but, for simplicity, in this walkthrough you'll use a redirect rule in the URL Rewrite Module.

1. Create a file named web.config in the following folder:

Expand All @@ -49,38 +49,38 @@ For this walkthrough you will need to add a redirection logic to the webmail app

This is a rule that will redirect all requests for index.aspx to default.aspx.

Now open a web browser and make a request `http://localhost/webmail/index.aspx`. You will see that the browser got redirected to `http://localhost:8081/default.aspx`, which is basically an internal URL used by the webmail web application. Now you will configure the URL Rewrite rules to modify the HTTP Location header in the HTTP redirection responses so that the browser is redirected to a proper URL: `http://localhost/webmail/default.aspx`.
Now open a web browser and make a request `http://localhost/webmail/index.aspx`. Notice that the browser got redirected to `http://localhost:8081/default.aspx`, which is basically an internal URL used by the webmail web application. Now you'll configure the URL Rewrite rules to modify the HTTP Location header in the HTTP redirection responses so that the browser is redirected to a proper URL: `http://localhost/webmail/default.aspx`.

## Modifying the inbound rule to preserve the host header

In order to be able to modify the HTTP Location header it is necessary to preserve the original value of the HTTP host header. The outbound rewrite rule will use the preserved value when modifying the response. To preserve the original value you will store it in a temporary server variable ORIGINAL\_HOST.
In order to be able to modify the HTTP Location header, it's necessary to preserve the original value of the HTTP host header. The outbound rewrite rule uses the preserved value when modifying the response. To preserve the original value, store it in a temporary server variable ORIGINAL\_HOST.

1. In the main URL Rewrite feature view page click "View Server Variables..." in the **Actions** pane on the right hand side:
1. In the main URL Rewrite feature view page, select **View Server Variables** in the **Actions** pane on the right hand side:
![Screenshot of View Server Variables under Manage Server Variables in the Actions pane.](modifying-http-response-headers/_static/image3.png)
2. In the "Allowed Server Variables" page click "Add..." and then enter the name of the server variable that will be used to temporarily store the value of the HTTP Host header, e.g. ORIGINAL\_HOST:
2. In the **Allowed Server Variables** page, select **Add** and then enter the name of the server variable that will be used to temporarily store the value of the HTTP Host header. For example, ORIGINAL\_HOST:
![Screenshot of Server variable name set to ORIGINAL underscore HOST.](modifying-http-response-headers/_static/image5.png)
3. Click OK to save the changes and then return to the main URL Rewrite feature view page. After that select the "Reverse Proxy to webmail" inbound rule and click "Edit..."
4. In the "Edit Inbound Rule" page, expand the "Server Variables" group box; then click "Add..." and enter "ORIGINAL\_URL" for the server variable name and "{HTTP\_HOST}" for the "Value":
3. Select **OK** to save the changes and then return to the main URL Rewrite feature view page. After that, select the "Reverse Proxy to webmail" inbound rule and select **Edit**.
4. In the **Edit Inbound Rule** page, expand the "Server Variables" group box; then select **Add** and enter "ORIGINAL\_URL" for the server variable name and "{HTTP\_HOST}" for the "Value":
![Screenshot of the Edit Inbound Rule page with Set Server Variable Value set to curly brace H T T P underscore HOST curly brace.](modifying-http-response-headers/_static/image7.png)

## Creating an outbound rule to modify the HTTP response header

Now you will create an outbound rewrite rule that will rewrite the HTTP Location header in redirection responses to add back the application folder to the URL path and to replace the host name.
Now you'll create an outbound rewrite rule that rewrites the HTTP Location header in redirection responses to add back the application folder to the URL path and to replace the host name.

1. In the main URL Rewrite feature view page click "**Add Rules...**" and then select "**Blank Rule**" under the "**Outbound Rules**" category.
2. In the "**Edit Outbound Rule**" page name the rule as "**Rewrite Location Header**".
3. In the "**Pre-condition**" drop-down list choose "**<Create New Pre-Condition...>**".
4. In the "Add Pre-Condition dialog" name the pre-condition as "**IsRedirection**"
5. Click "**Add**..." and then enter **{RESPONSE\_STATUS}** as a condition input and "**3\d\d**" as the pattern. This pre-condition will be used to check if the response has a redirection status code, e.g. 301, 302, 307, etc. The pre-condition dialog will look similar to below:
1. In the main URL Rewrite feature view page, select "**Add Rules**" and then select "**Blank Rule**" under the "**Outbound Rules**" category.
2. In the "**Edit Outbound Rule**" page, name the rule as "Rewrite Location Header".
3. In the "**Pre-condition**" drop-down list, choose "**<Create New Pre-Condition>**".
4. In the "**Add Pre-Condition**" dialog, name the pre-condition as "**IsRedirection**"
5. Select "**Add**" and then enter **{RESPONSE\_STATUS}** as a condition input and "**3\d\d**" as the pattern. This pre-condition is used to check if the response has a redirection status code, such as 301, 302, 307, and so on. The pre-condition dialog should look similar to the following:
![Screenshot of curly brace RESPONSE underscore STATUS curly brace set as an input and 3 backslash d backslash d set as the pattern.](modifying-http-response-headers/_static/image9.png)
6. Click OK to return to the "**Edit Outbound Rule**" page.
7. In the "**Match**" group box use the "**Matching scope**" drop down list to select "**Server Variable**".
8. Enter "**RESPONSE\_Location**" for the "**Variable name**" and "__^http://[^/]+/(.\*)__" for the "**Pattern**". This will configure the rule to operate on the response HTTP header "Location" and match its value against a regex pattern that will store the URL path into a back-reference.
9. Expand the "**Conditions**" group box, click "**Add...**" and enter **{ORIGINAL\_URL}** as a condition input and "**.+**" as a condition pattern. This condition checks if the temporary server variable ORIGINAL\_URL exists and has a non-empty value.
10. Click "**Add...**" one more time and add another condition. Set the condition input to **{URL}** and the pattern to "__^/(webmail|payroll)/.\*__". This regular expression will be used to match the URL paths that start with either /webmail or /payrol. Also the parenthesis within the pattern will capture the part of the matched URL string, so that it can be re-used when constructing the replacement URL.
11. Finally, in the "**Action**" group box choose the "**Rewrite**" action and enter "`http://{ORIGINAL_URL}/{C:1}/{R:1}`" as a value. This action will replace the value of the HTTP Location header with a string constructed by using the host name from the server variable, the condition back-reference that contains the URL path folder prefix and the rule back-reference that contains the current URL path in the Location header.
6. Select **OK** to return to the **Edit Outbound Rule** page.
7. In the **Match** group box, use the **Matching scope** drop-down list to select **Server Variable**.
8. Enter **RESPONSE\_Location** for the "**Variable name**" and "__^http://[^/]+/(.\*)__" for the "**Pattern**". This configures the rule to operate on the response HTTP header "Location" and match its value against a regex pattern that stores the URL path into a back-reference.
9. Expand the "**Conditions**" group box, select "**Add**" and enter **{ORIGINAL\_HOST}** as a condition input and "**.+**" as a condition pattern. This condition checks if the temporary server variable ORIGINAL\_HOST exists and has a non-empty value.
10. Select **Add** one more time and add another condition. Set the condition input to **{URL}** and the pattern to "__^/(webmail|payroll)/.\*__". This regular expression is used to match the URL paths that start with either /webmail or /payroll. Also, the parenthesis within the pattern captures the part of the matched URL string, so that it can be reused when constructing the replacement URL.
11. Finally, in the "**Action**" group box choose the "**Rewrite**" action and enter "`http://{ORIGINAL_URL}/{C:1}/{R:1}`" as a value. This action replaces the value of the HTTP Location header with a string constructed by using the host name from the server variable, the condition back-reference that contains the URL path folder prefix and the rule back-reference that contains the current URL path in the Location header.

The complete page will look as below:
The complete page should look like the following:

![Screenshot of the Edit Outbound Rule pane with ORIGINAL HOST and U R L set as condition input.](modifying-http-response-headers/_static/image11.png)

Expand All @@ -92,4 +92,8 @@ To test that the rules work correctly, open a web browser and make a request to

## Summary

In this walkthrough you have learned how to use several new features in URL Rewrite 2.0 to implement a fully functional reverse proxy scenario. You have configured the inbound rule to forward the requests to a backend content servers and to set a temporary server variable. Then you have defined an outbound rule that modifies the HTTP Location header in the redirection response generated by the web application from the backend content server.
In this walkthrough:

* You've learned how to use several new features in URL Rewrite 2.0 to implement a fully functional reverse proxy scenario.
* You've configured the inbound rule to forward the requests to a back-end content server and to set a temporary server variable.
* You've then defined an outbound rule that modifies the HTTP Location header in the redirection response generated by the web application from the back-end content server.