Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

404 Response Code #170

Open
nickschuch opened this issue Aug 26, 2017 · 6 comments
Open

404 Response Code #170

nickschuch opened this issue Aug 26, 2017 · 6 comments
Labels
question waiting Waiting for something

Comments

@nickschuch
Copy link

I am trying to use this as a backend behind a load balancer.

The backend returns a 404, I am able to replicate with a curl request (works via my browser).

$ curl -I http://127.0.0.1:8025
HTTP/1.1 404 Not Found
Content-Type: text/plain; charset=utf-8
X-Content-Type-Options: nosniff
Date: Sat, 26 Aug 2017 11:40:42 GMT
Content-Length: 19

I am going to do some debugging, wanted to create an issue to see if others have seen this behavior.

@Nakilon
Copy link

Nakilon commented Jan 14, 2019

-I is a HEAD request -- yes, it gives me 404 too.

@tyndyll
Copy link
Member

tyndyll commented Feb 19, 2019

Can you provide some details on what you mean by "behind a load balancer"? This will help us reproduce

@tyndyll tyndyll added question waiting Waiting for something labels Feb 19, 2019
@nakilon-idwell
Copy link

nakilon-idwell commented Feb 19, 2019

This is enough to reproduce:

$ curl -s http://user:password@...:8025 -o /dev/null -w '%{http_code}\n'
200
$ curl -s http://user:wrongpassword@...:8025 -o /dev/null -w '%{http_code}\n'
401
$ curl -sI http://user:password@...:8025 -o /dev/null -w '%{http_code}\n'
404

The last request is HEAD, not GET. The mailhog server had to respond with 200, not 404.

@vaisov
Copy link

vaisov commented Nov 4, 2020

Same happens to me when using behind Nginx. Nginx config I'm using: https://gist.github.com/blakethepatton/7928abb131593fd192606b681ee47b2b

Started with this, but it didn't work either: #117 (comment)

Found the solution for nginx at least. Instead of

location /mail {
       proxy_pass                        http://localhost:8080;

using (added trailing slash)

location /mail/ {
       proxy_pass                        http://localhost:8080/;

@voyc-jean
Copy link

Additional note. If you're running Mailhog behind a reverse proxy / loadbalancer and you're binding it to a different path, the MH_UI_WEB_PATH env var (or -ui-web-path parameter) should be set.

Example with Caddy:

localhost.com/mail* {
    reverse_proxy 0.0.0.0:8025
    tls internal
}

~/go/bin/MailHog -ui-web-path mail

@UncleTawnos
Copy link

The same problem here
Scenario:
kubernetes, regular nginx ingress controller with rewrite-target set to /
path /mailhog directs to mailhog ui and MH_UI_WEB_PATH is set to 'mailhog'
I get 404

api has started with correct path:
[HTTP] Binding to address: 0.0.0.0:8025
Creating API v1 with WebPath: /mailhog
Creating API v2 with WebPath: /mailhog
[APIv1] KEEPALIVE /api/v1/events

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question waiting Waiting for something
Projects
None yet
Development

No branches or pull requests

7 participants