Proxy.cgi : Error message when use wildcard in WPAD Excluded URL s

Since the upgrade from core version 170 I can no longer update the proxy settings
indeed, the interface refuses urls with wildcard that I had entered in previous versions in WPAD Excluded URL s
I get the error “Invalid url **”

I corrected in my /var/ipfire/

Line 764
-		$domainname = $1;
+		$domainname =~ s/^\*\.|\*//g;

that works !

If you can explain, why your version of function validwildcarddomainname($) is better and valid for the whole system, you are invited to send a patch. :wink:

More seriously:

  • why do you use “**”? Without the trailing ‘*’ the domain would be accepted.
  • changes in must be valid system-wide.

BTW: Welcome to our IPFire community.

thank you for your reply

Apparently the validwildcarddomainname($) function is only used for proxy.cgi and was added in this version 170

My explanation:

The proxy.pac file (wpad.dat

generated by ipfire contains only shExpMatch(url, …) arguments

in this case, to bypass the proxy you have to go through ‘*’

Example: If I block adult sites in url filter

and I still want to allow

  (shExpMatch(url, "**")) -> bypass works (i can access to

  (shExpMatch(url, "*")) -> bypass not working

To not use the ‘*’ at the end, the proxy.pac would have to be generated with

  (shExpMatch(host, "*")) -> bypass works

I don’t know how to send a patch, nor how to test the whole system.

best regards.

@pscar13 , your findings are right. :frowning:

I’ve made an annotation in the associated bugzilla case. I hope the correction finds its way in CU171.

Could you please try the suggested change?

Hi Bernhard,

I suspect that Michael and the others filter bugzilla to show newly raised bugs, for prioritisation and then probably sort all open bugs by change date so they can see if there are any important bugs.

That is what I do (so I can decide those bugs that are simple enough for me to work on) and the annotation you made does not show up in my lists and probably not in the devs bugzilla views either.

You could either re-open the bug (in my view not recommended in this case) or raise a new bug which you make a link to the closed bug you have highlighted.

Hi Adolf,

thanks for your hint.
I’ll open a new ticket.

EDIT: ticket #12937

1 Like

Thank you :+1:

Good evening,

The ticket is closed but the problem is still present in CU 172

Bug 12937 is still open. I think you must have looked at another bug number.

It is probably something that i can deal with but i still have an existing list of bugs and package updates to work on together with personal commitments before i can have a closer look at it.

Of course it is available for anyone else to pick up and deal with if they are willing to do so. They would be welcomed to join the small band of developers supporting IPFire.


I followed the previous link

Thank you for reply

Ah clear. No problems.

That was why i suggested a new bug because a closed one doesn’t get looked at and a new one made more sense than opening that previous one.

Here is the link to the current bug for easier checking.

1 Like

Hi @pscar13

I have had a look at this bug and it is simple enough for me to slot it into my activities now.

Can you confirm that you have tested out the specific change mentioned by @bbitsch in Comment 1 in the bug report?
If you haven’t tested it I will still submit the patch but some confirmed testing would be good.
I don’t use any wild card exclusions in my wpad.


Yes, I tested the fix you suggested in CU171:

sub validwildcarddomainname($) {
	my $domainname = shift;

	# Ignore any leading dots
	if ($domainname =~ m/^\*\.([^\*]*)\*?/) {
        $domainname = $1;

	return &validdomainname($domainname);

I tested the Proxy.cgi with the values


to avoid video stream caching

it is OK for me

The wpad.dat file is well updated


1 Like

Patch has been submitted. If it is accepted then it should get into CU173