Matcher: / vs * and some issues with MIME Type

Don’t know how to title this but I’m sure it’s interesting for some and should be found that way^.
I’m mostly writing this because of the mime-error. If anyone knows more about that I would be happy to hear you.

I’ll simply describe two Caddyfiles with the only difference being in there matcher (/ and *).
In both cases, we access a backend server using the reverse_proxy directive.

Caddy version: v2.1.1 h1:X9k1+ehZPYYrSqBvf/ocUgdLSRIuiNiMo7CvyGUQKeA=

Caddyfile #1

Let’s have a look at the first case:

sub.domain.tld {
	reverse_proxy / localhost:19999 
}

And at the website when opening sub.domain.tld in the browser. Console output:

Refused to apply style from 'https://sub.domain.tld/main.css?v=5' because its MIME type ('') is not a supported stylesheet MIME type, and strict MIME checking is enabled.
Refused to execute script from 'https://sub.domain.tld/main.js?v20190905-0' because its MIME type ('') is not executable, and strict MIME type checking is enabled.
Refused to execute script from 'https://sub.domain.tld/dashboard.js?v20190902-0' because its MIME type ('') is not executable, and strict MIME type checking is enabled.

And as you might guess already the website is shown without CSS and is non-functional due to missing js. Images aren’t shown either.
No other files are requested leading to only having 5 requests made, each with status-code 200.

Caddyfile #2

now let’s change the matcher to *.

sub.domain.tld {
	reverse_proxy * localhost:19999
}

Shouldn’t change much, or?
Now the website loads correctly, with CSS, JS and images. And now we have around 37 network requests made, all with status code 200 [okay, one 404 but that file should be missing :slight_smile: ]

So what happened?

In the second Caddyfile, we used a wildcard matcher. Proxying everything to our backend.


but in the first Caddyfile, we used a strict path matcher which only matches the exact path and no other.

A path matcher with a wildcard (/*) should have worked too. But /* can be shortened to * (afaik - don’t see any difference behind).

reverse_proxy docs for fast access:


But… I still don’t know why the mime error occurred instead of a 404 error or any other HTTP error.

This is because Caddy served an HTTP 200 response for paths that are not /. Caddy was not configured to respond to any other path, so the default response is an empty HTTP 200.

There is a difference between /* and *. Specifically, * means “match anything”, while /* means “match any path”. There is a slight performance difference in that Caddy will need to compare the paths if you configure it with /* on every request, whereas with * no comparisons will happen. So using * (or just omitting the matcher entirely, which defaults to * as long as the first argument does not start with / or @) is slightly more performant.

And by slightly, we’re talking nanoseconds, i.e. negligible. But you are right anyway, semantically they are different.