Last updated on MARCH 08, 2017
Applies to:COREid Access - Version: 10.1.4.0.1 to 10.1.4.0.1 - Release: 10g to 10g
Information in this document applies to any platform.
Checked for relevance on 12-Apr-2010
You use the Preferred HTTP Host feature to specify a host name that matches all possible methods by which the host can be addressed. When you specify a value for the Preferred HTTP Host for a WebGate, and you specify the same value in a Host Identifier field, all policies that use the host identifier apply to all requests that the WebGate processes, regardless of how the request was addressed originally. For example, if you have a WebGate on a Web server on host1.company.com, you can set the Preferred HTTP Host value to host1.company.com. Any policy that you configure for host1 will be applied to a request sent to the host, no matter how the user addresses the resource.
For example, suppose that the user sets up an /etc/hosts file to map to the arbitrary host name my.host.com and requests the following URL:
The WebGate will use the Preferred HTTP Host when setting policies for this request, despite the URL that the user supplied. Requests for resources that match values in the Preferred HTTP Host field are redirected to the Access Server for policy evaluation. The Preferred HTTP Host feature prevents security holes that can be inadvertently created if a host's identifier is not included in the Host Identifiers list.
You enter the Preferred Host name in the Preferred HTTP Host field when you configure an AccessGate. The name you enter in this field must be one of the names entered in the Host Identifiers feature.
Configuring a Preferred HTTP Host forces WebGate to pass the preferred host string to the Access Server for policy evaluation instead of the host typed into the browser by the user. No matter what is typed into the browser, the Access Server always sees the preferred host.
Preferred HTTP Host Advantage: An advantage of using a Preferred HTTP Host instead of Host Identifiers is that you do not need to enter every possible name by which a host can be addressed. If you do not have a Preferred HTTP Host set for the WebGate, it tries to match the URL in the request using the HOST header in the HTTP request. This is somewhat unpredictable, and you need to include all possible permutations of the host and port in the Host Identifier list, which may not be possible.
Preferred HTTP Host Disadvantage: A disadvantage is that Preferred HTTP Host cannot be used with virtual Web hosting. If you must configure your policies to distinguish between the virtual hosts, you cannot use the Preferred HTTP Host setting because it will eliminate the distinctions between the hosts. You must, instead, disable this feature.
The virtual Web hosting feature of many Web servers enables you to support multiple domain names and IP addresses that each resolve to their unique subdirectories on a single virtual server. For example, you can host abc.com and def.com on the same virtual server, each with its own domain name and unique site content. You can have name-based or IP-based virtual hosting.
When a client makes a connection, the IP address to which the client connects is looked up in the internal IP hash table. If the lookup is successful, then the doc root of that IP is served.
Sign In with your My Oracle Support account
Don't have a My Oracle Support account? Click to get started
Million Knowledge Articles and hundreds of Community platforms