Bernhard Huber wrote:
> Perhaps setting always a LastModifiedHeader will help too.
This is one thing that Cocoon may want to include no matter what. Here are the list of
valid HTTP 1.1 Headers for responses:
Accept-Ranges
Age
ETag
Location
Proxy-Authenticate
Retry-After
Server
Vary
WWW-Authenticate
Brief overview for those who don't know:
Accept-Ranges: {bytes|none}
Allows the server to indicate it's acceptance of range requests for a resource.
Probably
not something we want to support at this time, so Cocoon should set this header to none
all the time.
Age: {seconds}
Allows the server to convey the number of seconds since the response (or revalidation)
was generated by the origin server. This is used for cache-generated responses. In
essence, the Caching mechanism must set this header.
ETag: {xyzzy|W/xyzzy|}
This has to do with Entity Tags, which I don't fully understand. If a developer
understands
it and can use it, then they can implement it.
Location: {absoluteURI}
This is the redirect header--handled by the Redirector in Cocoon.
Proxy-Authenticate: {challenge}
this is used in conjunction with a 407 Proxy Authentication Required response.
Retry-After: {HTTP date|seconds}
This is used in conjunction with a 503 service unavailable response. We can use this
when
we are compiling the initial sitemap and we receive requests.
Server: {product|comment}
This is usually used by the official web server, and it might be augmented to advertise
Cocoon....
Vary: {*|field-name}
The server should include this header with any cacheable responce that is subject to
server driven negotiation. Basically, it tells the client that the resource will only
vary on the list of field names in a POST message.
WWW-Authenticate: {challenge}
This MUST be included with the 401 Unauthorized message--usually taken care of by the
servlet container.
Beyond this, we have the Entity Header fields. These are used for BOTH requests and
response
messages. These are:
Allow
Content-Encoding
Content-Language
Content-Length
Content-Location
Content-MD5
Content-Range
Content-Type
Expires
Last-Modified
Again, the quick definitions of these headers are:
Allow: {GET|HEAD|PUT|http method type}
Used to specify the types of methods allowable for a resource. Must be present with
the 405 Method Not Allowed response. This is useful for forcing POST instead of GET
methods for forms, etc. Again, not something Cocoon needs to do out of the gate.
Content-Encoding: {content coding}
Used when additional encoding has been performed (like gzip) on the resource. After
applying the proper decoding, the resource is the same as identified by the
Content-Type
message.
Content-Language: {2 char language code}
Used to specify if the resource is specific to a locale. If this is omitted, the
content
is intended for all languages. This can be a comma separated list. Remember, this can
be both request/response. We can use this clue if we want to do internationalization
based on the HTTP header.
Content-MD5: {base64 encoding of 128 bit MD5 digest}
If the content is static, this could be useful to ensure the received document is valid
and has not been corrupted in transit.
Content-Range: {byte unit} {first-byte-pos}-{last-byte-pos}/{instance-length|*}
Used for only downloading a range of bytes (useful for reducing traffic on the net).
Content-Type: {mime-type}
We all know this one. Cocoon SHOULD set this _allways_.
Expires: {http date}
Specifies when a resource expires (absolute date). Used to help proxy and client cache
implementations. For resources that do not cache, it should be set to the same value
as
the Date header.
Last-Modified: {http date}
Specifies the absolute date/time when the resource was last changed. Used to help
proxy
and client cache implementaitons. This should be set by the Cache mechanism.
--
"Those who would trade liberty for
temporary security deserve neither"
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
