HTTP 1.1 Support in ISA Server

  • Article

This article describes the HTTP 1.1 feature support in Microsoft® Internet Security and Acceleration (ISA) Server 2004 and ISA Server 2006. The HTTP filter in ISA Server uses HTTP 1.1:

  • In Web proxy scenarios (forward proxy), when processing outbound Web requests.
  • In Web publishing scenarios (reverse proxy), when forwarding Web requests from clients to published Web servers.

ISA Server and ISA Server 2006 are partially compliant with the HTTP 1.1 RFC.

Issues

This section outlines features with which ISA Server is not fully compliant with the HTTP 1.1 RFC. For complete details about RFC 2616, see Hypertext Transfer Protocol -- HTTP/1.1 (https://go.microsoft.com/fwlink/?LinkId=40119).

Pipelining

As documented in RFC 2616: "HTTP requests and responses can be pipelined on a connection. Pipelining allows a client to make multiple requests without waiting for each response, allowing a single TCP connection to be used much more efficiently, with much lower elapsed time." Pipelining avoids some of the round-trip delay times associated with establishing TCP connections, and benefits connections over high-latency links.

ISA Server does not implement pipelining. Client request pipelining is supported, allowing a client to make multiple requests without waiting for each response. However, pipelining when sending requests to the Web server is not supported.

For more information about pipelining, see RFC 2616 Chapter 8.1 Persistent Connections (https://go.microsoft.com/fwlink/?LinkId=40120).

Compression

Compression allows data to be compressed before transfer. Compression is negotiated between the client and the server, where the client's HTTP request specifies that compression should be used, in the Accept-Encoding HTTP header.

ISA Server does not implement compression, and it never compresses or decompresses data.

Outbound Access

For outbound access (forward proxy), the Accept-Encoding HTTP header is always removed from the client request. The Web server does not return compressed content, and uncompressed data can be cached.

Inbound Access

For inbound access (Web publishing scenarios), you can determine whether the Accept-Encoding HTTP header is removed. This behavior is configured in each Web publishing rule, through the SendAcceptEncodingHeader COM property. This property is read/write with a default value of "false" for an ordinary Web publishing rule, and "true" for a Microsoft Outlook® Web Access publishing rule created using the Mail Publishing Rule Wizard in ISA Server Management. For more information about this property, see SendAcceptEncodingHeader Property in ISA Server SDK Help in MSDN (https://go.microsoft.com/fwlink/?LinkId=40121).

After you set this value to allow the ISA Server computer to forward Accept-Encoding headers, and the client sends a header indicating that it will accept compressed content, the Web server may send a compressed response (indicated by its Content-Encoding header) that will be accepted by the ISA Server computer. However, the compressed content will not be cached.

For more information about compression, see RFC 2616 Chapter 3.5 Content Codings (https://go.microsoft.com/fwlink/?LinkId=40122).

Caching Directive

Cache directives specify cache behavior during requests and responses, so that caches can perform accurately and efficiently. ISA Server supports the HTTP 1.1 cache directives described in RFC 2616 (including Etags), with the exception of:

  • If-unmodified-since

  • If-match

    Note

    If-match is equivalent to If-unmodified-since, and neither are supported by ISA Server.
    If-none-match is equivalent to If-modified-since, and both are supported by ISA Server.

    For more information, see RFC 2616 Chapter 13 Caching in HTTP (https://go.microsoft.com/fwlink/?LinkId=40123).

Chunked Transfers

Chunked encoding modifies the body of a message to transfer it as a series of chunks, each with its own size indicator, followed by an optional trailer containing entity-header fields.

This allows dynamically produced content to be transferred along with the information necessary for the recipient to verify that it has received the full message.

ISA Server Standard Edition supports chunked transfers from the server (HTTP response), but does not support chunked transfers from the client (HTTP POST).

For more information, see RFC 2616 Chapter 3.6.1 Chunked Transfer Coding (https://go.microsoft.com/fwlink/?LinkId=40124).

Vary Headers

The Vary field value indicates the set of request header fields, such as Accept-Language or Accept-Encoding, that the server should use to determine (while the response is fresh) whether a cache is permitted to use the response to reply to a subsequent request without revalidation. For responses that cannot be cached or stale responses, the Vary field value advises the user agent about the criteria that were used to select the representation.

This is typically used for Web sites that deliver different content for the same URL, based on specific HTTP header information, such as Accept-Language. It allows the Web site to inform cache devices that different content can be delivered based on the set of request header fields included in the Vary header.

ISA Server supports caching of HTTP responses that contain only one relevant request header field in the Vary header list. For example, if an HTTP response contains a Vary header with only the Accept-Language request header field, the ISA Server cache will maintain all responses for the same URL based on the value of the Accept-Language header. If the HTTP response contains more than one relevant request header field in the Vary header, ISA Server will not cache this HTTP object.

For more information, see RFC 2616 Chapter 14.44 Vary (https://go.microsoft.com/fwlink/?LinkId=40125).

Upgrade Headers

The Upgrade header allows the client to specifiy what additional communication protocols it supports, and prefers to use if the server switches protocols. The server must use the Upgrade header within a 101 (Switching Protocols) response to indicate the protocol being switched. The Upgrade header field provides for a simple transition from HTTP 1.1 to some other protocols. The acceptance and use of the Upgrade header by the server is optional.

ISA Server does not support the Upgrade header. If a client sends a request containing this header, it is ignored by ISA Server. Both client and server will use standard protocols.

For more information, see RFC 2616 Chapter 14.42 Upgrade (https://go.microsoft.com/fwlink/?LinkId=40126).