Not working with local domains

[raghavendra89]

I've installed the smee client and set up the smee channel. The following command works fine:

smee --url https://smee.io/my-channel-id --path /github/webhook --port 8000

It delivers all payloads to http://127.0.0.1:8000/github/webhook url properly. But if I use my local domain which I've setup with Valet, it doesn't work.

Here is my command:
smee --target http://myapp.test/github/webhook --url https://smee.io/my-channel-id

I also tried supplying port, but it doesn't work:
smee --target http://myapp.test:8000/github/webhook --url https://smee.io/my-channel-id

Am I missing anything here?

[gr2m]

the usage looks correct to me ... could you try to find out what's going wrong? Maybe you caught a bug

[simensen]

I'm seeing something similar. It looks like my actual server (http://myapp.test:8000/github/webhook based on the OP example) isn't actually receiving the request from smee-client. smee-client is somehow catching a 404 response from the target, but my server isn't actually being forwarded. I'll include more details if I can figure out exactly what is going on here, but I suspect it might have something to do with the host header getting dropped somewhere? I'm not using Valet at the moment, but I'm guessing the target URL is being resolved correctly but maybe being accessed by IP or in some way in which the original host isn't being propagated to the request smee-client is making against my server. In my case I'm using traefik instead of Valet.

[simensen]

Oh, hey, this was fast! :) I think I was correct, here. In the case of both Valet and my traefik setup, the idea is to host multiple sites between one endpoint/reverse proxy. So, my setup looks like this:

NODE_TLS_REJECT_UNAUTHORIZED=0 \
    smee \
    --url https://smee.io/mVGuv0UG42AdJ7wA \
    --target https://prdeploy.test/github-app

I started digging into the logs a little deeper and I can see what's going on here:

reverse-proxy_1  | time="2021-12-12T00:00:51Z" level=debug msg="Serving default certificate for request: \"smee.io\""
reverse-proxy_1  | 10.211.55.2 - - [12/Dec/2021:00:00:51 +0000] "POST /github-app HTTP/1.1" 404 19 "-" "-" 1947 - - 0ms

It looks like smee-client is passing on the original host (smee.io) from the URL to the target host. Since my app is listening on prdeploy.test and not smee.io, it's throwing a 404. I'm guessing the same thing happens with Valet since it is a reverse-proxy machine sorta like what traefik is doing.

Ideally, I would have expected in my case for the target host to NOT be dropped. I sorta thought it was weird (unexpected?) that the port and path were specified independently when the --target required a full URL.

If we wanted to support this behavior, what would be the best way to do so? :) Should we add a flag like --keep-original-host or something?

[simensen]

Looks like this is likely related to #162. I'm going to send an alternative patch as I don't know if deleting the host header is the correct move here.

[mhermosi]

is myapp.test a virtual host on your web server? if that is the case the web server uses the HOST header to resolve the HTTP request. smee passes HOST=smee.io instead of the --target hostname which produces a series of problems including if you have ssl certificates

[craigrileyuk]

Just come across this same issue too.

Valet uses dnsmasq to allow using domains in the .test namespace, but smee doesn't seem to work with them. It's resolving to my valet server, but only returning a 404 which suggests it's not resolving to the correct site.

As a workaround, I had to run php artisan serve and use 127.0.0.1:8000 as my endpoint.