I think you probably meant to post this to the list...
On Mon, 2002-05-13 at 11:46, Terrel Shumway wrote:
> On Sat, 2002-05-11 at 13:27, Ian Bicking wrote:
> >
> > Otherwise, it might be possible to route a request through Webware, and
> > then have it do an internal redirect to the actual location of the
> > resource. However, this may be insecure -- if you knew what the
> > ultimate destination was you could short circuit the authentication.
> > Unfortunately, I don't think you can do an internal redirect to a
> > resource not available as a normal URL (i.e., just in the filesystem).
> > If you could (and you very possibly can, I don't even really understand
> > what Apache's doing with internal redirects), that would provide a
> > solution as well.
>
> Feature Request for mod_webkit NG:
>
> Allow an internal redirect to an otherwise inaccessible file, possibly
> filtering the result through other modules (e.g. mod_gzip, mod_xdelta,
> mod_patch[1]).
Yes, I had thought about this as well, and I thought I had put something
on the Wiki, but I can't find it now so I must have been imagining
that. Instead of mod_patch, I imagine you could use SSI, mod_layout, or
somesuch thing.
The adapter should include an environmental variable that indicates it
supports this feature, and then HTTPResponse should have a method like
serveFile or writeFile (writeFile if a mod_patch-ish thing was to
exist), and it would either use the special header if the adapter
supported it, or use the standard read/write loop if not. An adapter
also may not support this if it was not on the same computer as the
AppServer.
This *may* already be possible with internal redirects and fancy
mod_webkit rules (I believe you can write a RewriteCond that only
catches internal redirects, for instance). But that's also not portable
in the same way this would be.
> How? maybe don't use the normal redirect mechanism at all, but allow
> mod_webkit to just sendfile("path/to/private/file/cache/file.html").
>
>
> status: 200 Ok
> [normal headers]
> content-type: application/x-rpm
> x-webkit-sendfile: wkcache/foo/bar/fj823270jf/myfile-299.00.2-1.src.rpm
>
> or
>
> status: 200 OK
> x-webkit-patch: source=wksource/foo/templates/myfile.template;id=0
> x-webkit-patch: source=wkcache/foo/f3432/myfile.partial;id=1
> x-webkit-patch-length: 504
>
> [patch instructions here ..., probably with additional source data at
> the end.]
>
>
> Why? For the same reasons you would use apache/mod_webkit in the first
> place instead of a native python HTTP listener.
>
> (This message is mostly a note to myself for when I get around to
> porting mod_webkit to apache 2.0 (a long way off right now), or to
> anyone else who may beat me to it.)
>
> -- Terrel
>
>
>
> [1] mod_patch is currently vaporware. The idea is to merge content from
> multiple sources, often one from the filesystem (the base template or
> cached partial result) and another from webkit (customizations based on
> request and session data).
>
>
_______________________________________________________________
Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: [EMAIL PROTECTED]
_______________________________________________
Webware-discuss mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/webware-discuss
