- From: Johannes Koch <johannes.koch@fit.fraunhofer.de>
- Date: Thu, 06 May 2010 15:37:36 +0200
- To: ERT WG <public-wai-ert@w3.org>
Hi ERT group,
Johannes Koch schrieb:
> However, a creator tool must then have knowledge about which headers are
> to be considered entity headers and which not.
in HTTP/1.1 (<http://www.w3.org/Protocols/rfc2616/rfc2616.html>) there
are four types of header fields:
* General Header Fields (section 4.5),
* Request Header Fields (section 5.3),
* Response Header Fields (section 6.2), and
* Entity Header Fields (section 7.1).
General header fields are defined:
--- snip ---
general-header = Cache-Control ; Section 14.9
| Connection ; Section 14.10
| Date ; Section 14.18
| Pragma ; Section 14.32
| Trailer ; Section 14.40
| Transfer-Encoding ; Section 14.41
| Upgrade ; Section 14.42
| Via ; Section 14.45
| Warning ; Section 14.46
General-header field names can be extended reliably only in combination
with a change in the protocol version. However, new or experimental
header fields may be given the semantics of general header fields if all
parties in the communication recognize them to be general-header fields.
Unrecognized header fields are treated as entity-header fields.
--- snip ---
Request header fields are defined:
--- snip ---
request-header = Accept ; Section 14.1
| Accept-Charset ; Section 14.2
| Accept-Encoding ; Section 14.3
| Accept-Language ; Section 14.4
| Authorization ; Section 14.8
| Expect ; Section 14.20
| From ; Section 14.22
| Host ; Section 14.23
| If-Match ; Section 14.24
| If-Modified-Since ; Section 14.25
| If-None-Match ; Section 14.26
| If-Range ; Section 14.27
| If-Unmodified-Since ; Section 14.28
| Max-Forwards ; Section 14.31
| Proxy-Authorization ; Section 14.34
| Range ; Section 14.35
| Referer ; Section 14.36
| TE ; Section 14.39
| User-Agent ; Section 14.43
Request-header field names can be extended reliably only in combination
with a change in the protocol version. However, new or experimental
header fields MAY be given the semantics of request- header fields if
all parties in the communication recognize them to be request-header
fields. Unrecognized header fields are treated as entity-header fields.
--- snip ---
Response header fields are defined:
--- snip ---
response-header = Accept-Ranges ; Section 14.5
| Age ; Section 14.6
| ETag ; Section 14.19
| Location ; Section 14.30
| Proxy-Authenticate ; Section 14.33
| Retry-After ; Section 14.37
| Server ; Section 14.38
| Vary ; Section 14.44
| WWW-Authenticate ; Section 14.47
--- snip ---
So, by default, all other header fields appearing in HTTP messages are
to be considered entity header fields.
Entity header fields are defined:
--- snip ---
entity-header = Allow ; Section 14.7
| Content-Encoding ; Section 14.11
| Content-Language ; Section 14.12
| Content-Length ; Section 14.13
| Content-Location ; Section 14.14
| Content-MD5 ; Section 14.15
| Content-Range ; Section 14.16
| Content-Type ; Section 14.17
| Expires ; Section 14.21
| Last-Modified ; Section 14.29
| extension-header
extension-header = message-header
The extension-header mechanism allows additional entity-header fields to
be defined without changing the protocol, but these fields cannot be
assumed to be recognizable by the recipient. Unrecognized header fields
SHOULD be ignored by the recipient and MUST be forwarded by transparent
proxies.
--- snip ---
--
Johannes Koch
Fraunhofer Institute for Applied Information Technology FIT
Web Compliance Center
Schloss Birlinghoven, D-53757 Sankt Augustin, Germany
Phone: +49-2241-142628 Fax: +49-2241-142065
Received on Thursday, 6 May 2010 13:38:20 UTC