Appendix A:
HTTP Metainformation
This appendix provides a quick reference to HTTP metainformation, for use in metafiles, PHP scripts, and other mechanisms that can manipulate HTTP header fields. For most transactions, Stronghold determines the proper metainformation to use and you do not need to intervene. There are five kinds of HTTP metainformation fields:
- General
General metainformation is not specifically related to the client, server, or HTTP.
- Request
Request metainformation is used in HTTP client requests.
- Response
Response metainformation is used in HTTP server responses.
- Entity
Entity metainformation describes the data that follows the header.
- Proxy Security
Proxy security metainformation provides information about SSL-secured proxy connections.
General Headers
Both client requests and server responses use the general header fields listed in this section, although some are more commonly used by one or the other.
Cache-Control
Syntax: Cache-Control: directive1 [directive2 directive3 ...]
Context: general
Cache-Control sets the cache options for the current transactions. Requests and responses use separate directives.
The following are the possible request directives:
| Cache Request Directive |
Description |
no-cache |
Do not cache the request. |
no-store |
Remove the information immediately after forwarding the request. |
max-age=seconds |
Do not send responses older than the value specified by seconds. |
max-stale[=seconds] |
If max-stale appears alone, Stronghold is allowed to return expired data. If seconds is specified, Stronghold only sends data that has been expired for less than the given number of seconds. |
min-fres =seconds |
Return the data only if it has not expired by the specified number of seconds. |
only-if-cached |
Return only cached data. |
The following are the possible response directives:
| Cache Response Directive |
Description |
public |
Any host may cache the data. |
private |
A shared cache is not allowed to cache the data. |
no-cache |
Do not cache. |
no-store |
Remove the information immediately after forwarding the response. |
no-transform |
Do not convert the data to another format. |
must-revalidate |
Revalidate the data. |
proxy-revalidate |
Except when using a private cache, the client must revalidate the data. |
max-age=seconds |
The data expires in the specified number of seconds. |
Connection
Syntax: Connection: option1 [option2 ...]
Context: general
Connection specifies options specific to the current connection. For example, when keepalive is enabled, the client or server can use this field to close the connection:
Connection: close
Date
Syntax: Date: date time
Context: general
This field indicates the current date and time. RFC 1123 specifies the most current format for date and time, which looks like this:
Thu, 14 November 1996 09:46:03 GMT
However, you can also use the older RFC 850 and ANSI C formats for backward compatability:
Thursday, 14-Nov-96 09:46:03 GMT
Thu Nov 6 09:46:03 1996
MIME-Version
Syntax: MIME-Version: version
Context: general
If this field is not included, the default value is 1.0. Otherwise, MIME-Version specifies the version of MIME used in the transaction. It is unnecessary if the message body does not conform to MIME.
Pragma
Syntax: Pragma: no-cache
Context: general
Pragma is generally an HTTP 1.0 field; in HTTP 1.1, Cache Control takes its place. The only value is "no-cache," which instructs a proxy to request the document from a server instead of retrieving it from the local cache.
Transfer-Encoding
Syntax: Transfer-Encoding: type
Context: general
This field specifies the type of encoding applied to the message body. The only value currently defined by HTTP is "chunked."
Upgrade
Syntax: Upgrade: protocol/version
Context: general
When using the response code 101 (Switching Protocols), this field specifies the prefered protocol and version.
Via
Syntax: Via: protocol host ["comment"] ...
Context: general
HTTP 1.1 requires that gateways and proxies use this field to specify which protocols and hosts process the transaction in transit between the client and the server. It is used to track message forwards, avoid request loops, and identify the protocol capabilities of intermediate hosts.
Client Request Headers
Clients include the headers listed in this section when transmitting requests to servers.
Accept
Syntax: Accept: type/subtype1[; q=qvalue][, type/subtype2[; q=qvalue] ...]
Context: request
The Accept header specifies one or more media types that the client can accept, ranked using an optional qvalue. The qvalue is a floating point number between 0 and 1, with 1 being the most preferred media type.
Accept-Charset
Syntax: Accept-Charset: char-set1[; q=qvalue][, char-set2[;q=qvalue]...]
Context: request
This header field specifies one or more character sets that the client can accept, ranked using an optional qvalue. The qvalue is a floating point number between 0 and 1, with 1 being the most preferred character set.
Accept-Encoding
Syntax: Accept-Encoding: encoding-type1[, encoding-type2 ...]
Context: request
This header field specifies one or more encoding schemes that the client can accept. It can contain as many encoding types as needed. If this field is omitted or is empty, then the client does not accept any encoding types.
Accept-Language
Syntax: Accept-Language: language1[; q=qvalue][, language2
[; q=qvalue] ...]
Context: request
This header field specifies one or more languages that the client can accept, ranked using an optional qvalue. The qvalue is a floating point number between 0 and 1, with 1 being the most preferred characters set. Language is a two-character abbreviation such as "en" for English, "de" for German, and so on.
Authorization
Syntax: Authorization: scheme credentials
Context: request
When Stronghold responds to a request with a WWW-Authenticate header, the client replies with the Authorization header, specifying an authentication scheme (such as basic or digest) and credentials (a username and password).
Cookie
Syntax: Cookie: name=value
Context: request
If a cookie is set for the requested URL, the client sends the cookie name with the request. If the client specifies multiple cookies, they must be separated by semicolons.
From
Syntax: From: email-address
Context: request
The From header specifies the email address of the user sending the request.
Host
Syntax: Host: hostname[:port]
Context: request
This header specifies the hostname and, optionally, the port number of the URI. HTTP 1.1 requires this field, for distinguishing between multiple hosts on the same server platform when the URL is ambiguous.
If-Modified-Since
Syntax: If-Modified-Since: date
Context: request
Clients can use this header to instruct the server to send the document only if it has been modified since the date. If the document has not been modified since the given date, Stronghold responds with status code 304 (Not Modified). Usually, the client then retrieves a local cached copy.
If-Match
Syntax: If-Match: entity-tag
Context: request
This is a conditional header that requests the document only if it matches the specified entity-tag, which can take wildcard strings.
If-None-Match
Syntax: If-None-Match: entity-tag
Context: request
This is a conditional header that requests the document only if it does not match the specified entity-tag, which can take wildcard strings.
If-Range
Syntax: If-Range: entity-tag|date
Context: request
This is a conditional header that can only be used in conjunction with a Range header. The value can be either an entity tag or a date, indicating a partial entity that the client has already received.
If-Unmodified-Since
Syntax: If-Unmodified-Since: date
Context: request
This is a conditional header that requests a document only if it has not been modified since the given date. The value for date should follow the format specified in the Date header.
Max-Forwards
Syntax: Max-Forwards: n
Context: request
This header limits the number of hops between the client and server to n.
Proxy-Authorization
Syntax: Proxy-Authorization: credentials
Context: request
When Stronghold acts as a proxy server, clients use this header instead of the Authorization header.
Range
Syntax: Range: bytes=n-m[,n-m ...]
Context: request
A client can use this header to request one or more segments of a document. The segments are specified with bytes ranges separated by commas.
Referer
Syntax: Referer: URL
Context: request
The Referer header indicates the URL of the document that refers to the requested URL, meaning the document in which the user followed a link to the request document.
User-Agent
Syntax: User-Agent: string
Context: request
This header gives information about the client, such as the application, version number, platform, and so on.
Server Response Headers
Stronghold uses the headers listed in this section to respond to client requests.
Accept-Ranges
Syntax: Accept-Ranges: bytes|none
Context: response
When a client requests a segment of a document using the Range header, Stronghold responds with Accept-Ranges to indicate a successful range request.
Age
Syntax: Age: seconds
Context: response
Stronghold can use this header to specify the age of the message body in seconds.
Proxy-Authenticate
Syntax: Proxy-Authenticate: scheme realm
Context: response
When Stronghold responds with the 407 (Proxy Authentication Required) status code, is also sends this header to indicate the authentication scheme (such as basic or digest) and the authentication realm (set with the AuthName directive).
Public
Syntax: Public: method1[,method2,method3 ...]
Context: response
Public indicates one or more request methods that Stronghold supports. To indicate methods supported only for an individual URI, use the Allow header instead.
Retry-After
Syntax: Retry-After: date|seconds
Context: response
When Stronghold uses the 503 (Service Unavailable) status code, it also sends this header to indicate when the client should resubmit the request. The value can be either a date (in a format specified by the Date header) or an integer indicating a period of seconds.
Server
Syntax: Server: string
Context: response
The Server header specifies the name and version number of the server, including its Apache core. In Stronghold Web Server 3.0 Administration Guide's case, this is
Server: Stronghold/3.0 Apache/1.3.1
Set-Cookie
Syntax: Set-Cookie: name=value[; expires=date; path=pathname; domain=domain; secure]
Context: response
The Set-Cookie header passes a cookie to the client for use with the requested URL. Only the name value is required.
Vary
Syntax: Vary: *|headers
Context: response
The Vary header indicates that the requested document exists in more than one form, and that the form sent with the response is affected by one or more specified request headers. The value is "*" if the document form is affected by factors other than request headers.
Warning
Syntax: Warning: code host[:port] "string"
Context: response
Stronghold uses the Warning header to expound on status code information. This is usually used by caching proxies. Code is a two-digit code, and string is the recommended descriptive string for the code, as follows:
| Code |
String |
10 |
Response is stale |
11 |
Revalidation failed |
12 |
Disconnected operation |
13 |
Heuristic expiration |
14 |
Transformation applied |
99 |
Miscellaneous warning (or an arbitrary string) |
Host is the hostname of the server or one of its virtual hosts, with an optional port number.
WWW-Authenticate
Syntax: WWW-Authenticate: scheme realm
Context: response
When Stronghold responds with the 401 (Unauthorized) status code, it also sends this header to indicate the authentication scheme (such as basic or digest) and the realm (set with the AuthName directive), so that the client can return the appropriate username and password.
Entity Headers
Entity headers supply information about the message body in an HTTP message, which can be either a client request or a server response.
Allow
Syntax: Allow: method1[,method2,method3 ...]
Context: entity
This header indicates acceptable request methods for the requested URI. When Stronghold uses this header in a response, it is combined with the 405 (Method Not Allowed) status code.
Content-Base
Syntax: Content-Base: URI
Context: entity
Content-Base specifies an absolute URI to use as a base for all relative URLs.
Content-Encoding
Syntax: Content-Encoding: encoding-type[,encoding-type,encoding-type ...]
Context: entity
This header specifies one or more encoding types used to encode the message body, in the order in which they were used. The possible values for encoding-type are as follows:
"gzip"
"x-gzip"
"compress"
"x-compress"
Content-Language
Syntax: Content-Language: language
Context: entity
Content-Language specifies the language used in the message body, using a two-character code such as "en" for English, "de" for German, and so on.
Content-Length
Syntax: Content-Length: bytes
Context: entity
This header gives the length of the message body in bytes. In dynamic requests, this figure is often unknown; in that case, the header can be omitted.
Content-Location
Syntax: Content-Location: URI
Context: entity
When a document exists in several locations, Stronghold can include this header in the response to indicate the source of the copy it sends to the client.
Content-MD5
Syntax: Content-MD5: digest
Context: entity
The client can use this header to check the integrity of the message. Digest is an MD5 digest of the message body.
Content-Range
Syntax: Content-Range: bytes n-m/length
Context: entity
When the client requests a partial document using the Range header, Stronghold can respond with the Content-Range header to indicate which segment is enclosed in the message body. The values are a byte range and the total number of bytes in the segment.
Content-Transfer-Encoding
Syntax: Content-Transfer-Encoding: scheme
Context: entity
If Stronghold transforms the message body for transfer over the network, it uses this header to specify the encoding type, such as "7bit," "8bit," "binary," "base64," or "quoted-printable."
Content-Type
Syntax: Content-Type: type/subtype
Context: entity
Stronghold uses this header to specify the media type and subtype of the message body. Generally, the server returns media types that the client specifies with the Accept header.
ETag
Syntax: ETag: entity-tag
Context: entity
When a client send an If-Match or If-None-Match header, Stronghold responds using the ETag header, which specifies the entity tag for the requested document.
Expires
Syntax: Expires: date
Context: entity
Stronghold can use this header to indicate when the requested document expires. After the given date, a proxy server may refresh its cached copy of the document.
Last-Modified
Syntax: Last-Modified: date
Context: entity
The Last-Modified header indicates when the document was last modified.
Location
Syntax: Location: URI
Context: entity
When Stronghold responds with a status code such as 201 (Created), 301 (Moved Permanently), or 302 (Moved Temporarily), it includes the Location header to indicate the source of the requested document. URI must be absolute.
URI
Syntax: URI: <URI>
Context: entity
HTTP 1.1 deprecates this header in favor of Location, but it can still be used for backward compatability.