Example: HTTP routing with full URL & host name rewriting
In some cases, HTTP header-based routing is not enough. It must be, or should be, combined with request or response rewriting.
Example.com hosts calendar, inventory, and customer relations management web applications separately: one app per specialized server. Each web application resides in its web server’s root folder ( / ). Each back-end web server is named after the only web application that it hosts:
• calendar.example.com/
• inventory.example.com/
• crm.example.com/
Therefore each request must be routed to a specific back-end web server. Requests for the calendar application forwarded to crm.example.com, for example, would result in an HTTP 404 error code.
These back-end DNS names are publicly resolvable. However, for legacy reasons, clients may request pages as if all apps were hosted on a single domain, www.example.com:
• www.example.com/calendar
• www.example.com/inventory
• www.example.com/crm
Because the URLs requested by clients (prefixed by /calendar etc.) do not actually exist on the back-end servers, HTTP header-based routing is not enough. Alone, HTTP header-based routing with these older location structures would also result in HTTP 404 error codes, as if the clients’ requests were effectively for:
• calendar.example.com/calendar
• inventory.example.com/inventory
• crm.example.com/crm
To compensate for the new structure on the back end, request URLs must be rewritten: FortiWeb removes the application name prefix in the URL.
For performance reasons, FortiWeb also rewrites the Host: field. All subsequent requests from the client use the correct host and URL and do not require any modification or HTTP-based routing. Otherwise, FortiWeb would need to rewrite every subsequent request in the session, and analyze the HTTP headers for routing every subsequent request in the session.
See also
