Project

General

Profile

Actions

Bug #3210

closed

Unexpected 403 after multiple reloads in lighttpd 1.4.70

Added by flynn over 1 year ago. Updated over 1 year ago.

Status:
Duplicate
Priority:
Normal
Category:
mod_access
Target version:
ASK QUESTIONS IN Forums:
No

Description

The following configuration:

$HTTP["remoteip"] !~ "^(...some ipv4 numbers...)" {
  $HTTP["scheme"] == "https" {
    $HTTP["url"] !~ "^/(...some urls ...)" {
      $HTTP["remoteip"] != "one ipv4 subnet" {
        url.access-deny = ( "" )
      }
    }
  }
}

works as expected.

But if I open an URL in Firefox, that reloads itself continously every 60sec (<meta http-equiv="refresh" content="60">), after some time I get a 403.
Forcing a reload in firefox solves the problem and the problem may return. It's not easy to reproduce.

This is lighttpd 1.4.71, I'm sure it existed already in 1.4.70, but I cannot say exactly which version introduced the problem.
All requests are HTTP/2 with TLS.

Looking in the access log I see, that the log line with the return 403 contains an IPv6 address, which explains the 403 decision inside lighttpd. All lines before contain the correct IPv4 address. The user agent of all lines is the same! Some lines before I also see a localhost address (127.0.0.1) with the Firefox user agent, which cannot be correct.

The needed reloads to trigger the problem is at least around 60.

The IPv6 address found belongs to other (dutch) clients on some lighttpd instance (germany) found in the same access log, so I guess lighttpd is mixing up client ips ...


Related issues 1 (0 open1 closed)

Is duplicate of Bug #3207: Segfaults after upgrade to version 1.4.70FixedActions
Actions #1

Updated by flynn over 1 year ago

According to my understanding so far: to reproduce the problem you need two URLs with two different clients IPs/subnets/protocols(IPV4/6), both periodically retrieving their URLs at similar intervals, in my case 60sec.

Actions #2

Updated by gstrauss over 1 year ago

There was an issue introduced in lighttpd 1.4.70, and thought fixed in #3207, which is part of lighttpd 1.4.71.

Please confirm that you are still seeing a similar issue with lighttpd 1.4.71. Thank you.

I'll try to look into your IPv4 vs IPv6 observation.

Actions #3

Updated by gstrauss over 1 year ago

(For others reading this: after a new version of lighttpd is deployed to a production machine, it is important that running lighttpd executable be restarted.)

Actions #4

Updated by flynn over 1 year ago

I my case: I build new debian packages, but did NOT install them on this server.

New Test with version 1.4.71 is running, but at the moment the additional remote traffic is missing to trigger the issue. I have to wait for tomorrow.

Actions #5

Updated by gstrauss over 1 year ago

  • Subject changed from Unexpected 403 after multiple reloads to Unexpected 403 after multiple reloads in lighttpd 1.4.70
  • Status changed from New to Duplicate
  • Target version changed from 1.4.72 to 1.4.71

My apologies that the bug was not caught in my load tests when extending lighttpd code for #3192.

Actions #6

Updated by gstrauss over 1 year ago

  • Is duplicate of Bug #3207: Segfaults after upgrade to version 1.4.70 added
Actions #7

Updated by flynn over 1 year ago

No errors with version 1.4.71 so far, issue can be closed.

Maybe a note to version 1.4.70 should be added, that it can break access rules.

Actions

Also available in: Atom