cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Ball <ba...@webslingerZ.com>
Subject Re: Content-length
Date Sun, 23 Jan 2000 19:55:45 GMT
On Sun, 23 Jan 2000, [iso-8859-1] Nicolás Lichtmaier wrote:

>  I like Cocoon. I think it might be the way all things should happen in the
> web. But to do that Cocoon must be as `web friendly' as posible, as static
> pages are. e.g. it must send the proper HTTP headers in order to cooperate
> with caches and other HTTP software. From reading the sources it seems very
> easy to add the Content-length header. The whole content is first stored in
> a String (in Engine.handle()). It would be a matter of sending the
> string.length();. This could be done now... is there any reason this is not
> being done?

no good reason that I'm aware of. i'll commit the patch if others agree.
+1 from me.

>  Last-modified/Expires is a little more complicated, but I have a proposal:
> 
>  You can always add these headers by hand, but this approach is wrong, as
> these headers could be easily handled automatically. This is how:
> 
>  The `Last-modified' date is the greater `last-modified' date of all
> components of the producer|processor path. Tha `Expires' header is the
> lesser date. This is obvious if you think a bit about it. The simple
> producer that reads a file would give the files' date as the last-modified
> time, later, a producer that adds some information from some files would
> report those files' date. The greater date would be the `last-modified'
> header.
> 
>  This could be implemented with a PI like this:
> 
> <?last-modified value="<a time>"?>
> 
>  Each component in the path would be able to create this PI. The engine
> *will remove this PI* before sending the document to the next component. The
> engine will keep the bigger last-modified time. If a component does not
> provide this information, last-modified generation would be cancelled. The
> same would be done with the expires (only that it would keep the smaller
> time).
> 
>  What do you think?

I think there are other issues at work here that we have to worry about.
We need some way to ask the XML parser for the most recently modified date
of any resource referenced by an XML file that it's parsing (so as to
account for external entities). Similarly, we need some way to ask the XSL
processor the same question (so as to account for xsl:import/include). I'm
not certain that we have either of these facilities yet. Perhaps someone
more conversant with the latest generation of X*L tools could chime in.

- donald


Mime
View raw message