* Akins, Brian wrote: > I started to play with xsendfile more. I noticed the mod_xsendfile > floating around tried to basically replace what the default handler does > very well. > > Basically, my version does a subrequest for the file. This allows things > like "Deny from all", etc, to work. This should be more secure, ie, if > you set your deny's correctly, you can't "X-Sendfile: /etc/passwd". All > in all, it seems more "httpd"-like, to me. > > It is very rough. I do not understand brigades enough to know why it is > chunking every reply in my tests. I have tested with just a normal cgi > setting the header. > > Not well tested. I'd like to see us work toward getting X-sendfile into > the normal httpd distribution (along with mod_fcgid...)
Interesting. I wrote something similar a time ago for mod_proxy_scgi, also aimed to be extracted into the core. And hey, it's nearly the same stuff we're doing there, so it can't be that wrong :-) So +1 to have something in the core. http://people.apache.org/~nd/mod_proxy_scgi/mod_proxy_scgi.c The chunked problem is present there, too, but I solved it by ignoring it (you might search for Content-Length for more comments). If it should not be chunked, the backend simply has to provide a content-length along with the x-sendfile header. I'm split: I'm not sure if a filter is semantically the right place. IMHO that smells a bit problematic. It might be better to I'd rather hack that into a function similar to ap_internal_redirect and let it call explicitly. That way you'd need to hack a recognition per backend (but the code is mostly there anyway), on the other hand you could enable and disable it per backend. I like the idea of having its own module. Opinions highly welcome. nd -- > [...] weiß jemand zufällig, was der Tag DIV ausgeschrieben bedeutet? DIVerses. Benannt nach all dem unstrukturierten Zeug, was die Leute da so reinpacken und dann absolut positionieren ... -- Florian Hartig und Lars Kasper in dciwam
