dokuwiki not in root problem of regexp

Francis Daly francis at
Sat Jun 30 15:42:17 UTC 2012

On Sat, Jun 30, 2012 at 10:25:41AM -0400, Jiff wrote:

Hi there,

> > > In my mind it _should_ be: "location
> > ~/dokuwiki/(data|conf|bin|inc)/"
> > 
> > That looks to me like it should also work...

...for /dokuwiki/data/, but not for /dokuwiki/something/data/ -- the
difference may not matter here.

> (I must say I didn't understand it fully: eg: at this time
> I don't really know the difference between .* and (.*)  ).

"perldoc perlre". The short version is: capture.

> > What one url did you access to test this?
> conf say:  root
> (I've set an authoritative zone for it in the LAN,
> returning:
> I access it by:

The specific url you tried was

> > What response did you see?
> - - [30/Jun/2012:07:37:40 +0200] "GET
> /dokuwiki/lib/tpl/default/images/button-dw.png HTTP/1.1" 444 0
> "" "Mozilla/5.0 (X11; U; Linux i686;
> en-US; rv: Gecko/20120603 Iceape/2.0.11"

HTTP 444 is not a standard return code. It is used within nginx as a
"just close the connection" signal. The config you have shown does not
include 444 anywhere that I can see.

> 444 is what I intend to use when stable; however, for 
> tests my block is:
> location ~ /dokuwiki/(data|conf|bin|inc)/ {
>    return 403;
> }

/dokuwiki/lib/tpl/default/images/button-dw.png does not match this
location, and so this config will not be used.

Also, it looks like you are using,
not, as the starting point. Is
that expected?

> > What response did you expect to see?
> a 200 one

According to the config you posted,
/dokuwiki/lib/tpl/default/images/button-dw.png should return the content
of the file /var/www/dokuwiki/lib/tpl/default/images/button-dw.png or
else 404.

> location ~ \.php$ {

> location ~ /dokuwiki/(data|conf|bin|inc)/ {

> location ~* \.(js|css|png|jpg|jpeg|gif|ico)$  {

That is the one that will match this one request.

> location /dokuwiki {

> location   @dokuwiki {

I don't see how the config you posted can lead to the access log you
posted. Maybe someone else will have better luck. Maybe enabling the
debug log will give more hints to where the problem it.

> > Does the example config in
> >
> > _id=2388 provide any
> > useful hints?
> Oh, I see; but there's something strange: he only modify one path;
> but others nest in the same place, so he logically should have
> split the original block in 4 blocks, no? (last post).

Probably not. At that point it that report, they are talking about
"xsendfile" and are learning that nginx is not the same as apache.

It's not directly related to what you are reporting.

All the best,

Francis Daly        francis at

More information about the nginx mailing list