-
-
Notifications
You must be signed in to change notification settings - Fork 4k
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
Max retries exceeded with HTTP->HTTPS redirects #3201
Comments
To clarify: Debug mode doesn't disable auto HTTPS redirects -- it has nothing to do with them -- it just enables DEBUG level logging (which there isn't too much of at this point, but I'm sure more will be added with time). What exactly are you trying to test? What's the problem here, exactly? Your config is served over HTTPS, but redirects to HTTP, I assume for a host that is served by the same config, hence the loop. I'll need more info in order to be helpful, since just saying "some error" and using clipped or redacted configs isn't going to get us anywhere. :) Ideally, we need to be able to reproduce the bug in the most minimal way possible. This allows us to write regression tests to verify the fix is working. If we can't reproduce it, then you'll have to test our changes for us until it's fixed -- and then we can't add test cases, either. I've attached a template below that will help make this easier and faster! It will ask for some information you've already provided; that's OK, just fill it out the best you can. 👍 I've also included some helpful tips below the template. Feel free to let me know if you have any questions! Thank you again for your report, we look forward to resolving it! Template
Helpful tips
Example of a tutorial: Create a config file: |
@dragonpaw something that has been added recently is the ability to do some internal integration testing. caddy/caddytest/integration/caddyfile_test.go Lines 29 to 52 in 178ba02
This will work with public hostnames, internally it will dial localhost instead of the public dns ip address. Lines 222 to 226 in 178ba02
This will not however work with ACME servers but with a small modification to your Caddyfile you could use caddy's new internal CA (smallstep) to issue certificates for you or you can use locally made self signed certs (the If you are comfortable running some go code.
Finally this is a new testing approach which has few bugs on Windows, if you are a windows user your experiences could help with #3191 Let me know if this is useful. |
I didn't expect it to. I was hoping it might add interesting info to the logs. It didn't, but that's a different issue.
I am expecting to be able to 100% verify that a configuration under test behaves properly before I let it within 10 miles of production. There's absolutely zero chance that I will deploy an http config, that I haven't tested. Running an httpd within a container and sending it http requests with appropriate Host headers is a pretty good way to be sure that it will behave as desired once it's in use. To that end, I should be able to configure it for, as in this example, to redirect 'example.com/~ash/foo' to 'ash.example.com/foo`. I wish to be able to verify that the config I has will reliably do that, long, long before it's anywhere near production hosts. If I cannot confirm that, I will consider the service unsuitable for production use, and never use it. I'm not about to try to debug httpd configs in production when I can do so before then. Perhaps this is a philosophical thing. But for me, as a long-time devops engineer, software needs to be able to be tested before it reaches production. So I'm looking for help in finding out if caddy is appropriate for me in this way.
That's cool, but neither of those are true. The config wasn't redacted, and the error message was exactly pasted. (As seen in the last line of the 3rd code block: I referred to the error as "some error" on the text directly below the error.
Cool, so the config I provided will do exactly that. It's 100% reproducible with the information I've provided. I can even upload the resulting docker container someplace if you like. I shortened the config enough to prove it was reproducible, which is I think maybe what you incorrectly labeled as 'redacting'.
The only thing I didn't give before is the version of docker I was using for the build. But sure...
Docker 2.2.0.4 under Windows 10-64,
Not built from source.
Because opinionated old SREs won't put services in production if they can't be put under test. So if I can't bounce a http request off of it with appropriate Host headers, and see the redirects and content I expect to, there's no way I'll ever let it be used by real clients.
Can't find any.
|
@dragonpaw As per their issue the recommendation is to edit your
Btw here is an integration test for you (no hosts name changes needed)
|
Good find on the httpie bug! Thank you. Given that, I think what would have helped in this case would be two things:
|
|
You can force http by
The error message you were getting was
But unless you understand how TLS and SNI work that might not mean much. The TLS / SNI processes are quite separate from the hostname matching. Sure docs on the use of curl would handy for anyone in a SRE role. |
Not sure where you saw the 'no certificate ... for localhost' message, as I never got that one. I do think some documentation and logging improvements would help in these kinds of situations, but as I have enough to continue now, feel free to close the issue if you'd like. Thank you for your help. |
I've got a moderately complex setup that I'm trying to migrate from nginx to Caddy2, with redirects and regex and fun stuff like that. So of course I want to run this thing locally and double check the config before putting it in place in production. Unfortunately, this kinda seems impossible with the https features as it is today.
Given this Dockerfile:
And a Caddyfile that looks a little like:
I'd want to be able to do a lot of testing on the redirects and such before, but, using httpie for local test:
So I can't do the tests over http, since it always redirects to https, even in debug mode, and this doesn't seem able to be disabled. And trying using https gives some error that doesn't seem to have anything to do with local certificates. And I can't use this in production where the hostnames actually route to the host, because I can't test it.
I'm really not sure how to make progress at this point.
The text was updated successfully, but these errors were encountered: