Questions regarding spdy module, browser behaviour and "access forbidden by rule"

Server NGINX
1

[Not sure if this is the right list, because I’m uncertain if the
following is intended behaviour or a problem in nginx or the involved
browsers. So would be happy if you guys could me give some advice and a
pointer in case, this mail should better be directed elsewhere; if so,
sorry for the noise.]

[Iceweasel is the name of Firefox in Debian.]

Hi all,

I’ve got a server running a current Debian Wheezy and nginx
1.6.1-1~bpo70+1. Like this suggests, the packages (nginx-common and
nginx-extras) are installed from wheezy-backports. This server got one
private ip, the traffic to and from the public internet gets routed by
haproxy on a different machine.

I’ve tried out the spdy module to test how this changes page load times
etc.

On the webserver I’m hosting some static content, an etherpad and a
dokuwiki. I’ve put the configuration for the dokuwiki vhost at [1].

This works just fine with Chromium 35.0.1916.153-1~deb7u1 (out of
wheezy) and Iceweasel 24.8.0esr-1~deb7u1 (out of wheezy), no problems
loged, neither in the browser, nor in the nginx logs.

However, using Iceweasel 31.0-1~bpo70+1 (out of wheezy-backports), the
browser console reads various 403 forbidden, and the nginx log is
telling me the cause: "[…] 25108#0: *200 access forbidden by rule,
client: XX.XX.XX.XX, server: wiki.example.com, request: “GET
/lib/exe/js.php?tseed=1395165407 HTTP/1.1 […]”.

I’ve got no clue how to debug this, to be honest. I didn’t made any
change, just upgrading one of the involved browsers.
Could this be an incompatibility with this new Iceweasel version?
Any ideas for this?

And one more question: I’ve tried (because of these failures) to enable
spdy just on some vhosts, but it seems, enabling spdy in one of these
makes all vhosts using it. Is this correct? Could I circumvent this
using two ips, one spdy enabled, and one spdy disabled?

Thanks in advance,
cheers,
Georg

P.S.: Nginx is awesome - thanks for your work!

[1] http://pastebin.com/raw.php?i=BPynrmLg

2

On Wednesday 03 September 2014 20:18:50 georg wrote:
[…]

However, using Iceweasel 31.0-1~bpo70+1 (out of wheezy-backports), the
browser console reads various 403 forbidden, and the nginx log is
telling me the cause: "[…] 25108#0: *200 access forbidden by rule,
client: XX.XX.XX.XX, server: wiki.example.com, request: “GET
/lib/exe/js.php?tseed=1395165407 HTTP/1.1 […]”.

I’ve got no clue how to debug this, to be honest. I didn’t made any
change, just upgrading one of the involved browsers.
Could this be an incompatibility with this new Iceweasel version?
Any ideas for this?

That’s very strange. Could you provide a debug log?
http://nginx.org/en/docs/debugging_log.html

And one more question: I’ve tried (because of these failures) to enable
spdy just on some vhosts, but it seems, enabling spdy in one of these
makes all vhosts using it. Is this correct? Could I circumvent this
using two ips, one spdy enabled, and one spdy disabled?

Yes, this is correct and documented: Module ngx_http_core_module
Note, that it “allows accepting SPDY connections on this port”.

And yes, two ips will help.

wbr, Valentin V. Bartenev

3

Hi Valentin,

Thanks for your help.

On 09/03/2014 10:23 PM, Valentin V. Bartenev wrote:

Could this be an incompatibility with this new Iceweasel version?
Any ideas for this?

That’s very strange. Could you provide a debug log?
A debugging log

Sure. I’ve posted it at [1], the log contains one access, just made with
spdy enabled, and Iceweasel out of wheezy-backports.

Greetings,
Georg

[1] http://pastebin.com/raw.php?i=ei9wHeAy

4

On Wednesday 03 September 2014 23:50:07 georg wrote:

client: XX.XX.XX.XX, server: wiki.example.com, request: "GET
Sure. I’ve posted it at [1], the log contains one access, just made with
spdy enabled, and Iceweasel out of wheezy-backports.

[…]

It’s not clear how it’s related to SPDY and Iceweasel, but it looks
like misconfiguration on your side.

In the debug log I see that docuwiki returns X-Accel-Redirect to
“/var/lib/dokuwiki/data/cache/…” which is matched by location
~/(data|conf|bin|inc)/ with a deny rule.

wbr, Valentin V. Bartenev

5

On 09/04/2014 12:39 AM, Valentin V. Bartenev wrote:

and haven’t been noticed due to browser’s cache.

But update of the browser could result in reset of the cache.

I thought of something similar, and to be sure I’ve used the build-in
“Restart with addons disabled”-function of Iceweasel. At starting up it
will then offer two choices: Either start with addons disabled (so
called “Safe Mode”) or reset Iceweasel, which will clear all caches,
settings, etc. Using the second option in Iceweasel out of wheezy (after
I’ve downgraded Iceweasel out of backports to Iceweasel of of stable)
didn’t made a difference, all was fine, no errors reported.

6

On 09/04/2014 12:04 AM, Valentin V. Bartenev wrote:

I’ve got no clue how to debug this, to be honest. I didn’t made any
[…]

It’s not clear how it’s related to SPDY and Iceweasel, but it looks
like misconfiguration on your side.

Still I don’t understand why enabling spdy makes this difference, and
how this influences stuff like this, but…

In the debug log I see that docuwiki returns X-Accel-Redirect to
“/var/lib/dokuwiki/data/cache/…” which is matched by location
~/(data|conf|bin|inc)/ with a deny rule.

…you put me on the right track, Valentin!

  • These locations are denied because these contain for example content,
    like cached pages, one could access without authorization. The wiki is
    closed, reading and editing is only possible after successfull
    authentification, so that’s why.

  • Dokuwiki supports a header “X-Accel-Redirect”, which, when using,
    should increase file transfers etc., because then handled directly by
    the webserver. Up until today I’ve used this setting. After disabling,
    everything works like a charm, with all browsers (and different
    versions) I’ve tested (Chromium, Iceweasel, MSIE, Opera, Safari).

  • Still I don’t understand why using this feature (in combination with
    spdy) works in Iceweasel 24, and giving these failures in Iceweasel 31.
    Anyway, some more people seem to have problems with this (see [1] for
    example), at [2] and [3] you’ll find a bug report and a follow up,
    created in November 2011, fixed and closed in March 2014. I’m quite sure
    these changes haven’t reached Debian Wheezy, leading to this problem.

Thank you Valentin for your help - I’m fine.

Cheers,
Georg

[1] X-Accel-Redirect and "access forbidden by rule"
[2] FS#2388 X-Sendfile / Nginx X-Accel-Redirect passses wrong path
[3] FS#2388 Fix sendfile/X-Accel-Redirect on nginx by dom-mel · Pull Request #543 · dokuwiki/dokuwiki · GitHub

7

On Thursday 04 September 2014 02:04:09 Valentin V. Bartenev wrote:

telling me the cause: "[…] 25108#0: *200 access forbidden by rule,

~/(data|conf|bin|inc)/ with a deny rule.

Well, I can guess that you have made some change that broke these
resources,
and haven’t been noticed due to browser’s cache.

But update of the browser could result in reset of the cache.

wbr, Valentin V. Bartenev