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

Alert posting does not seem to follow HTTP redirects #668

Closed
quolix opened this Issue May 4, 2015 · 9 comments

Comments

Projects
None yet
4 participants
@quolix
Copy link

quolix commented May 4, 2015

I try running prometheus on Mesos, where jobs get assigned dynamic ports. I have an http redirector that redirects requests to specific hostnames to the correct hosts and ports on Mesos via 303/307/308. I want to use that to make prometheus POST its alerts to the alert manager.

However it seems that the redirect is never followed, indicated by tcpdump and netstat not showing any TCP traffic to the actual alert manager port.

@juliusv

This comment has been minimized.

Copy link
Member

juliusv commented May 5, 2015

Haven't looked deeply into this yet, but I'm wondering whether it has to do with this (redirects upon POST being problematic in HTTP in general because POST is not an idempotent operation): http://programmers.stackexchange.com/questions/99894/why-doesnt-http-have-post-redirect

@juliusv

This comment has been minimized.

Copy link
Member

juliusv commented May 5, 2015

Indeed, it looks like when Go is following redirects and the method is POST or PUT, it does subsequent redirected requests via GET: https://github.com/golang/go/blob/master/src/net/http/client.go#L353-L355

Not sure why you don't see any followup request (not even GET) in tcpdump, but it seems that redirecting POSTs doesn't really work well in general. Would it be possible to use a method of redirection which is transparent to the client?

Reading the code, it seems it might be possible to change Go's default behavior here by setting a custom CheckRedirect method on the HTTP client, but I'm kind of wary setting that for everyone...

@quolix

This comment has been minimized.

Copy link
Author

quolix commented May 5, 2015

Yes, that was my reading of the client.go awell.

However, the spec seems to indicate that a 307 must not result in a changed method:
http://www.heise.de/netze/rfc/rfcs/rfc7231.shtml#page-58

Bug in client.go then?

@juliusv

This comment has been minimized.

Copy link
Member

juliusv commented May 5, 2015

Interesting pointer. Yeah, the code does not make any differentiation for StatusTemporaryRedirect (307), so that looks buggy to me as well.

I found a bug reported about this already against Go, but the status is unclear - I left a comment: golang/go#7912

@juliusv

This comment has been minimized.

Copy link
Member

juliusv commented May 5, 2015

(That still doesn't explain why there was no followup request at all - I guess you verified that your redirector returns 307 with the appropriate headers?)

@quolix

This comment has been minimized.

Copy link
Author

quolix commented May 5, 2015

Both curl and Firefox/Chrome are happy with the redirector's responses.

@juliusv

This comment has been minimized.

Copy link
Member

juliusv commented Nov 23, 2016

@quolix FYI, golang/go#7912 has been fixed and the fix will be in Go 1.8. So once that's out and Prometheus uses Go 1.8, then this should work.

@brian-brazil

This comment has been minimized.

Copy link
Member

brian-brazil commented Jul 14, 2017

We're on Go 1.8 now.

simonpasquier pushed a commit to simonpasquier/prometheus that referenced this issue Oct 12, 2017

@lock

This comment has been minimized.

Copy link

lock bot commented Mar 23, 2019

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@lock lock bot locked and limited conversation to collaborators Mar 23, 2019

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.