Wrapping replies

Nickolay Saukh writes:
 > This idea came from phttpd TODO list.
 > 
 > For some replies there is a need for additional postprocessing
 > like character set translation, compression, wrapping in SSL, ...
 > Are there any plans to implement a dynamic built pipeline
 > (Unix Streams may be?) for that?
 > 
 > The design rationale does not go beyond "Compute the reply".


There is already the w3c.jigsaw.filters.ProcessFilter that allows you
to process the reply entity body through a UNIX process. Well
unfortunately due to some Java bug, I haven't been able to use it (it
should work at least on Win platforms). This filter can be plugged
either to a single resource, or to a DirectoryResource, in which case
it will apply to all resources that are children of it. So, this can
be used typically for things like (char set translation, compression,
etc) - ie anything that doesn't apply to the server as a whole.

SSL comes into an other category, since you probably want it to be
applied on each resources served by the server. At this point Jigsaw
doesn't come with the notion of "global filters" (although you can
still plug your filter on the server root resource, for the same
effect. Next release of Jigsaw should (if times allow) come with a
fearly elaborate model for these global filters, which would allow -
amongst other things - PEP (HTTP protocol extension protocol)
processing.  

Anyway, the main point is that SSL (and the like) will act behind the
scene, so you as a resource writer shouldn't care about it (as is the
case for chunk-encoding, for example). This is the main reason, in the
design, for *not* having resources emit back the reply themselves, but
rather leave it to some other object (at this point the
w3c.jigsaw.http.Client) to do it. BTW this differs, as far as I
understand from Jeeves for example.

Anselm.

Received on Sunday, 9 June 1996 14:47:35 UTC