cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicolás Lichtmaier <>
Subject Re: Content-length
Date Sun, 23 Jan 2000 20:30:24 GMT
> >  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.

 Note that you must do something about the <!-- served by Cocoon -->
message. I would move it up, and print it to the "out" stream too. You
should probably remove the "from cache" part.

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

 Agreed. This would be the responsibility of each component in the pipeline,
so we could take care of this later. What do you think about the
"infrastrcture" I propose?

 If a given component (one XSLT processor) doesn't provide the PI, it
doesn't matter. Cocoon will not send the `last-modified' (or `expires').

View raw message