Really weird bug?

General
1

Hello,

So while I was setting up my environment with Caddy, I noticed something really weird, I was using a domain with Caddy and there is an API I developed that I pass as a reverse proxy in the config.

All fancy stuff for now, as I figured out the right setup, BUT, while I was doing, I noticed something extra weird.

Using this config:

cs2darchive.com {
    log {
        output file /home/marcell/_domains/cs2darchive.com/logs/access.log
        level DEBUG
        format json
    }

    @cs2dapi path /api/*
    reverse_proxy @cs2dapi localhost:3415
    file_server
    @noCS2DAPI {
        not {
            path /api/*
        }
    }
    root @noCS2DAPI /home/marcell/_domains/cs2darchive.com/dist

    try_files * {path} /
}

My API endpoint cs2darchive.com/api/listClients throw this RESPONSE from the side of the Caddy:

[    0.914703] usbcore: registered new interface driver usbfs
[    0.920222] usbcore: registered new interface driver hub
[    0.925566] usbcore: registered new device driver usb
[    1.325815] usbcore: registered new interface driver lan78xx
[    1.331558] usbcore: registered new interface driver smsc95xx
[    1.952346] dwc2 1000480000.usb: supply vusb_d not found, using dummy regulator
[    1.960771] dwc2 1000480000.usb: supply vusb_a not found, using dummy regulator
[    2.218637] dwc2 1000480000.usb: EPs: 8, dedicated fifos, 4080 entries in SPRAM
[    2.225129] dwc2 1000480000.usb: DWC OTG Controller
[    2.240868] dwc2 1000480000.usb: new USB bus registered, assigned bus number 1
[    2.254232] dwc2 1000480000.usb: irq 37, io mem 0x1000480000
[    2.267641] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 6.08
[    2.279035] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    2.279038] usb usb1: Product: DWC OTG Controller
[    2.279039] usb usb1: Manufacturer: Linux 6.8.0-1004-raspi dwc2_hsotg
[    2.279041] usb usb1: SerialNumber: 1000480000.usb
[    3.091004] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 6.08
[    3.099315] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    3.106582] usb usb2: Product: xHCI Host Controller
[    3.111484] usb usb2: Manufacturer: Linux 6.8.0-1004-raspi xhci-hcd
[    3.117785] usb usb2: SerialNumber: xhci-hcd.0
[    3.131175] usb usb3: New USB device found, idVendor=1d6b, idProduct=0003, bcdDevice= 6.08
[    3.139490] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    3.146759] usb usb3: Product: xHCI Host Controller
[    3.151660] usb usb3: Manufacturer: Linux 6.8.0-1004-raspi xhci-hcd
[    3.151663] usb usb3: SerialNumber: xhci-hcd.0
[    3.242487] usb usb4: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 6.08
[    3.250795] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    3.258048] usb usb4: Product: xHCI Host Controller
[    3.262943] usb usb4: Manufacturer: Linux 6.8.0-1004-raspi xhci-hcd
[    3.269234] usb usb4: SerialNumber: xhci-hcd.1
[    3.281906] usb usb5: New USB device found, idVendor=1d6b, idProduct=0003, bcdDevice= 6.08
[    3.290209] usb usb5: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    3.297460] usb usb5: Product: xHCI Host Controller
[    3.302354] usb usb5: Manufacturer: Linux 6.8.0-1004-raspi xhci-hcd
[    3.308651] usb usb5: SerialNumber: xhci-hcd.1
[    5.446793] usbcore: registered new interface driver brcmfmac

Even I did not believe it, but when I tried to access the same API endpoint from localhost:3415/api/listClients, I was getting the actual correct response, rather than that weird dmesg kernel messages.

Normally my output on that endpoint is the one below, I know this not really relevant, but you see why I was WHOA once I got that unusual response above.

[
    {
        "id": 62,
        "version": "1.0.1.4",
        "os": {
            "win": true,
            "linux": true,
            "mac": false,
            "steam": true
        },
        "url": {
            "win": "http://cs2darchive.com/XXXX",
            "linux": "http://cs2darchive.com/XXXXXX",
            "steam": "steam://launch/666220/Dialog"
        },
        "available": true,
        "release_date": "2024-07-25T00:00:00.000Z",
        "release_type": "final",
        "size": {
            "mac": 1010000,
            "win": 6212371.2,
            "linux": 728850,
            "steam": 0
        },
        "hash": null,
        "downloadcount": "111",
        "require_dg": false,
        "special": null
    },
   ...
]

Is it concerning or some bug in the Log Routing?

I understand this is hard to believe, even myself was shocked, as I never experienced such an output.

2

Weird. To pinpoint it as a bug in Caddy, how can we reproduce the behavior?

1 Like
3

I can offer sending both the API and the script, other than that, I cannot of course validate 100% sure, it is caused by Caddy, but odd is it only happens, when I use the Proxy over Caddy and via localhost its good.

4

So if you use another proxy like nginx (in an identical config, or rather one that yields identical behavior to the Caddy config) it doesn’t happen?

1 Like
5

No, same config with OpenLiteSpeed before gave back the right response, this only happened during I switched to Caddy, but it only also occured when I’ve added the root ( * ) after try_files, that’s what I found at least.

6

Did you add that behavior to OpenLiteSpeed too?

1 Like
7

OLS didn’t require any additional setup like this, as you need to use web interface, but in that, I have simply received the response as I wanted.

I don’t have anything else to add really.

8

This is probably your problem. The try_files directive has a higher order than other directives, so it runs first, even for /api/* paths, so it’s probably rewriting your API requests to /.

Also, try_files does not take matchers because it’s a special shortcut for a longer bit of config which itself uses a matcher. So you would want to remove the * there.

This is probably what you’re intending with that config:

cs2darchive.com {
	log {
		output file /home/marcell/_domains/cs2darchive.com/logs/access.log
		format json
	}

	handle /api/* {
		reverse_proxy localhost:3415
	}

	handle {
		root /home/marcell/_domains/cs2darchive.com/dist
		try_files {path} /index.html
		file_server
	}
}

I strongly suggest serving content from /srv instead of /home. If you’re running Caddy as a systemd service (you should be if you’re running Caddy long-term) then the caddy user (that the caddy process will run as) will typically not have access to /home due to Linux directory permissions.

4 Likes
9

Even if as you are saying it rewrites the request to / makes no sense to output System Logs such as Kernel Messages. My API never write such a message not even on the root path, like I said, this only happened with Caddy.

Also as I mentioned, I already figured out the setup, but thank you.

10

You didn’t use the help topic template, so we’re missing a lot of context here. We don’t know how you’re running Caddy, which is key to having a clue as to why that was happening. Please use the Help category next time (not General) and fill out the template.

1 Like