httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Vas Dias <>
Subject [users@httpd] Re: denying access to SSI fragments
Date Wed, 06 Apr 2011 14:52:38 GMT
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 ?

I think httpd's SSI implementation is somewhat broken in that it appears impossible to include
a fragment
without exposing the fragment to valid HTTP/S requests .

This is the main reason I use HTML::Mason's '$m->comp(...)"  instead of SSI includes, which,
SHOULD be a useful httpd feature, but ISN'T , for the above reason.

What I've ended up having to do to allow non-Mason html pages to include fragments with SSI
without exposing the
 fragments to users is to write a "handler"  in "C" for all "include/*" content that parses
internal Apache data structures
 to see if the request orginated with an "SSI" , and only if it did,  returns the content

If anyone else would find such a handler module useful, I'll post it here - otherwise can
anyone explain how else to set
up apache to allow SSI requests but NOT allow  HTTP/S requests for a fragment ?

Thanks in advance for any responses (which I really do not expect to receive after all this
time on this issue ! )
and thanks for giving the world its best HTTP/S server

Regards, Jason 

On Monday 13 September 2010 16:05:48 Jason Vas Dias wrote:
> Sorry if this question has been answered somewhere else before,
> but searches of your site and google yielded nothing relevant.
> How can I deny access to fragments that are included with 
> server-side-includes (SSI) , ie. I want to be able to include
> a fragment:
>    '<!--#include virtual="/include/a_fragment"-->
> in an html page, but I don't want users to be able to request
>   '/include/a_fragment' .
> on its own ?
> All my attempts to do this by specifying access control on my
> '/include/' directory fail, because the SSI #include request is itself denied, 
> even though the request is coming internally from the server,
> not from not an external user . 
> I've tried specifying the include directory as :
>    '<Directory /include/>
>      ...
>      Deny from all;
>    '</Directory>'
> and
>     '<Directory /include/>
>      ...
>      Order Deny, Allow;
>      Deny from all;
>      Allow from;
>    '</Directory>'
> but both deny the SSI include requests as well as the external requests.
> Why must SSI include requests use the same originating IP details as the request
> for the whole page, since they are internal "request"s originating in the server ?
> Can anyone suggest a way of denying access to '/include/*' from external users, 
> while allowing '/include/*' to be targets of SSI #include requests ?
> Thanks in advance for any responses,
> Regards,
> Jason Vas Dias <>

The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:> for more info.
To unsubscribe, e-mail:
   "   from the digest:
For additional commands, e-mail:

View raw message