cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: let us get serious about 2.0 Final Release
Date Tue, 20 Nov 2001 20:35:32 GMT
Bernhard Huber wrote:

> Okay, nice list of headers to set.
> 
> Who sets what?
> What is already answered by you.
> 
> Who:


.5) HTTP Server


> 1) ServletEngine
> 2) Cocoon
> 2.1) CocoonReader
> 2.2) CocoonSerializer
> 2.3) CocoonGenerators


2.4) CocoonMRUStore (cache implementation)
2.5) CocoonServlet
2.6) CocoonAction


> I think that the ServletEngine won't set any headers, will reread the 
> servlet-spec...


There are some set by the HTTP server which may or may not be the
servlet engine.

Out of our control
------------------
Location: ServletEngine (Response.redirectTo())
Server: HTTP Server (can also be added to by Cocoon possibly?)
WWW-Authenticate: ServletEngine (Basic Authentication mechanism)
Proxy-Authenticate: HTTP Server
Content-Encoding: HTTP Server (unless implemented by us)

Our responsibility
------------------
Age: CocoonMRUStore
Vary: CocoonMRUStore/CocoonAction
Retry-After: CocoonServlet (during init time)
Content-Language: CocoonAction/CocoonGenerator/CocoonReader (i18n)
Content-Length: CocoonReader/CocoonMRUStore (only one where we know ahead of time)
Content-Location: CocoonServlet (repeat of the requested URI)
Content-MD5: CocoonReader/CocoonMRUStore (only one where we know ahead of time)--optional
Content-Type: CocoonSerializer
Expires: CocoonMRUStore
Last-Modified: CocoonMRUStore
Allow: CocoonAction/Sitemap?

Unknown responsibility
----------------------
Accept-Ranges
Content-Range
ETag


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



-- 

"Those who would trade liberty for
  temporary security deserve neither"
                 - Benjamin Franklin


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


Mime
View raw message