Updating url alias tables fails when remote server returns empty document.
Updated to 2.3 and it seems the url alias tables fails to update when one table contains no entry ("").
In my case I have a remote server dynamically generate the IP lists and quite often they contain no IPs at all.
A workaround in my case is to always add one invalid IP to the list (e.g. "18.104.22.168\n" ).
There were error(s) loading the rules: /tmp/rules.debug:186: macro 'UK_VPN_Clients_Bypass' not defined - The line in question reads : pass in quick on $LAN inet from $UK_VPN_Clients_Bypass to tracker 10000003 keep state label "NEGATE_ROUTE: Negate policy routing for destination" @ 2016-04-16 12:18:32
Updated by Phillip Davis over 5 years ago
Perhaps there could be a checkbox for URL table aliases that lets the user select what they want to do if the URL returns an empty table:
a) Keep the current data in the local table/alias or
b) Clear out the local table and (hopefully temporarily - until entries appear in the remote URL) disable any rules (or other stuff) that use it.
And perhaps the answer to the above question is different depending on why the remote URL seemed empty:
a) The name in the URL could not be translated
b) The resulting IP address + file could not be reached
c) No errors getting the remote file with the data - it really does seem to be empty
Updated by Chris Buechler about 5 years ago
- Status changed from New to Feedback
- Target version set to 2.3.2
- Affected Version changed from 2.3 to 2.3.x
fix pushed to prevent ruleset errors in that case. It just leaves an empty file there and still includes it in the ruleset, which is fine.
To address what Phil noted, the empty file only ends up there if the server returns something as part of a HTTP 200 response. If it gets a 200 reply and that reply parses to no valid contents, the file ends up empty, so the alias is blank but that's what the user told it to do. If it's a non-200 code, it won't replace the existing data and will omit usage of that alias entirely from the ruleset, because that table doesn't exist at all and hence cannot be used.