Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <3BFAB829.7030106@a1.net>
Date: Tue, 20 Nov 2001 21:08:09 +0100
From: "Bernhard Huber" <berni_huber@a1.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:0.9.4) Gecko/20011019 Netscape6/6.2
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: let us get serious about 2.0 Final Release
References: <20011018124926.13426.qmail@web12805.mail.yahoo.com>
 <01112011473701.00848@igacer> <1006266193.3bfa67511309c@mail.otego.com>
 <01112102354509.00848@igacer> <3BFA9C5B.4000503@a1.net>
 <3BFAAC8A.6050708@apache.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Okay, nice list of headers to set.

Who sets what?
What is already answered by you.

Who:
1) ServletEngine
2) Cocoon
2.1) CocoonReader
2.2) CocoonSerializer
2.3) CocoonGenerators
I think that the ServletEngine won't set any headers, will reread the 
servlet-spec...

I have not dived into Cocoon to understand 100% contracts for 
serializer, and generators, and
if they are allowed to set the http-headers.

But probably it's not the task of the serializer to set the http-headers.
Thus the http-headers should be set be Cocoon-Servlet after the request 
is handled.
Is this right?

I will take a look at Cocoon-1 implementation.

Berin Loritsch wrote:

> 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.


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org