Dear colleagues,
I need help with URL rewriting (fw 8.0.3 if it's important).
We have a "bad-coded" local site (let it be site.domain.local. suffix is .local, it's important). A lot of pages of this site contain hardcoded absolute URLs for file download (e.g. https://site.domain.local/storage/filename).
Also site has a builtin user authentication form. When user opens https://site.domain.local/ page the site engine checks that user isn's authenticated, calculates special hash and send 302 redirect message with Location: https://site.domain.local/loginform?hash=XXXX header.
Now we need to publish this site to internet via Fortiweb. We use public name site.company.com for publishing.
I created HTTP content routing policy for site.company.com -> site.domain.local. I also created web protection profile with URL rewriting policy. Policy contains 3 rules:
1. Rewrite request Host header site.domain.com -> site.domain.local (action Stop)
2. Rewrite response Location header site.domain.local -> site.domain.com (action Continue)
3. Rewrite response HTTP body - any site.domain.local -> site.domain.com (action Stop)
The problem is that policy works only when 1 & 2 rules are active. When I add rule 3 - policy stops working even for the login page which is about 1062 bytes long (header Location stays wrong)!
I suppose because of:
For a Response rewrite rule and the action is “Rewrite HTTP Body”, ensure there is a “Content-Type” header in the response from the backend server, and the Content-Type (also called Internet or MIME file types) must be supported by FortiWeb.
The first page with 302 redirect message doesn't contain any http body so there is no content-type header. And without the first page (where hash is calculated) we can't login. I tried different action combination for policy rewrite rules (e.g. stop after Location header rewrite), it doesn't help.
Am I right? Any suggestions? Looking forward for your help!
Hello JV_IT,
Thank you for using the Community Forum. I will seek to get you an answer or help. We will reply to this thread with an update as soon as possible.
Hello,
We are still looking for an answer to your question.
We will come back to you ASAP.
Hello again JV_IT,
I found this answer. Can you tell us if it helps, please?
To address the issue with URL rewriting on FortiWeb, especially when dealing with the "Rewrite HTTP Body" action, follow these steps:
Content-Type Header Requirement: For the "Rewrite HTTP Body" action to work, the response from the backend server must include a "Content-Type" header. Ensure that the response includes this header and that the Content-Type is one of the supported types by FortiWeb (e.g., text/html, application/json).
Rule Execution Order: Ensure that the rules are executed in the correct order. Since the "Rewrite HTTP Body" action requires a Content-Type header, it might be beneficial to adjust the order or conditions under which this rule is applied.
Buffer Size Consideration: Check if the response size exceeds the Maximum Body Cache Size. If the response is larger than the buffer size, the rewriting will not work. Increase the buffer size if necessary.
Testing and Logs:
diagnose debug flow filter module-detail url-rewrite 7
Alternative Approach: If the "Rewrite HTTP Body" action is not feasible due to the lack of a Content-Type header, consider alternative methods such as modifying the backend server to include the necessary headers or using a different approach to handle the URL rewriting.
By ensuring the presence of a Content-Type header and adjusting the buffer size, you should be able to resolve the issue with the URL rewriting policy. If the problem persists, further analysis using diagnostic logs may be required.
Dear Jean-Philippe,
Thanks for your post, but I also read the Troubleshooting Guide :) And I also wrote about a possible problem with the content header in my post. But what I can't understand is that according to official documents, the rules are followed in order until the first one matches. But what I see is that the general policy is checked for compliance, and the rules are followed only if all necessary conditions are met (the presence of the content-type header in my case). And that's strange for my opinion because this contradicts the documentation.
I found this answer for you:
In FortiWeb, URL rewriting rules are generally processed in the order they are configured, and the first matching rule is applied. However, for the "Rewrite HTTP Body" action, the presence of a "Content-Type" header is crucial because it determines how the body content is processed. If the "Content-Type" header is missing or unsupported, the rule may not execute as expected, which can seem like a contradiction to the rule order processing.
Here are some steps to consider:
Ensure Content-Type Header: Verify that the backend server includes a "Content-Type" header in its response. This is necessary for the "Rewrite HTTP Body" action to function correctly.
Rule Order and Conditions: Double-check the order of your rules and ensure that they are configured correctly. The rules should be processed in the order they appear, but specific conditions like the presence of headers can affect execution.
Diagnostic Logs: Use diagnostic logs to gain insights into how the rules are being processed. This can help identify if the absence of the "Content-Type" header is causing the issue.
Documentation Review: Revisit the official FortiWeb documentation to ensure that all configurations align with the recommended practices.
If the issue persists, consider reaching out to Fortinet support for further assistance, as they can provide more detailed guidance based on your specific configuration and environment.
If you want people to always land on the login page, why not let the Webserver serve the the people login page as default page? Sure you can achieve all of that on fortiweb, but I don't get why in this case tbh
As I mentioned already this site bad-coded and we are not in charge of it.
It is possible that your backend has a redirect too. Probably FortiWeb is receiving the request for the client in https and passing it to the backend in http, which return a 301 to https site.
In that case, I would disable it in the backend.
| User | Count |
|---|---|
| 2930 | |
| 1459 | |
| 869 | |
| 826 | |
| 455 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2026 Fortinet, Inc. All Rights Reserved.