httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Vas Dias <jason.vas.d...@gmail.com>
Subject Re: [users@httpd] Re: denying access to SSI fragments
Date Wed, 06 Apr 2011 15:16:54 GMT
On Wednesday 06 April 2011 15:58:29 you wrote:
> On Wed, Apr 6, 2011 at 10:52 AM, Jason Vas Dias
> <jason.vas.dias@gmail.com> wrote:
> > I don't understand why this question got no responses .
> >
> > Surely it is not an unreasonable request to ask the server to support
> > SSI requests like :
> >  \<\!\-\-\#include virtual\=\"include/head.html\"\-\-\>
> >  without also exporting "include/*" to be available to HTTP/S requests ?
> >
> > Of what meaning to users could a "head.html" or "footer.html" fragment be expected
to be ?
> 
> Virtual treats it like a normal request for that URL, so I would
> expect it to be an otherwise valid URL for a client.  "file" is an
> alternative.
>
Thanks for your response Eric !
Yes, but even with "file" the server will still "serve" those files and they must still be
"accessable"
to HTTP/S requests - I remember testing this a long time ago I was still able to send an HTTP
request for files included with "file" - the difference being that I lose the potential for
file to be
a cgi script and to get access to special SSI variables ? Or am I missing something ?
ie a DocumentRoot /www/ file contains:
   <!--#include (virtual or file)="some_dir/a_fragment"-->
The user must be "granted"  read access to "some_dir" and to "some_dir/a_fragment" - I don't
see how to overcome this except by a custom handler for "some_dir/" - or am I just a stupid
apache novice ?

 

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
   "   from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org


Mime
View raw message