Closed Pamalosebi closed 4 years ago
Thanks for opening an issue! We'll look into this.
It's not immediately clear to me what is going on, so I'll need your help to understand it better.
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. :+1:
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!
## 1. Environment
### 1a. Operating system and version
```
paste here
```
### 1b. Caddy version (run `caddy version` or paste commit SHA)
```
paste here
```
### 1c. Go version (if building Caddy from source; run `go version`)
```
paste here
```
## 2. Description
### 2a. What happens (briefly explain what is wrong)
### 2b. Why it's a bug (if it's not obvious)
### 2c. Log output
```
paste terminal output or logs here
```
### 2d. Workaround(s)
### 2e. Relevant links
## 3. Tutorial (minimal steps to reproduce the bug)
Environment: Please fill out your OS and Caddy versions, even if you don't think they are relevant. (They are always relevant.) If you built Caddy from source, provide the commit SHA and specify your exact Go version.
Description: Describe at a high level what the bug is. What happens? Why is it a bug? Not all bugs are obvious, so convince readers that it's actually a bug.
Tutorial: What are the minimum required specific steps someone needs to take in order to experience the same bug? Your goal here is to make sure that anyone else can have the same experience with the bug as you do. You are writing a tutorial, so make sure to carry it out yourself before posting it. Please:
curl
.Example of a tutorial:
Create a config file: ``` { ... } ``` Open terminal and run Caddy: ``` $ caddy ... ``` Make an HTTP request: ``` $ curl ... ``` Notice that the result is ___ but it should be ___.
Also, this seems like the panic should only happen if .php
isn't in the request. (It's even a TODO in the current code.) Can you fill out the above template (see the helpful tips) and let me know how to reproduce the bug?
--> btw. is there an alternative to the proxy { transparent } from caddy1? I always thought it is very handy.
Caddy 2 passes the headers thru by default, including the Host header, and adds X-Forwarded-For, so you don't need transparent
in v2.
See this guide for more info: https://caddyserver.com/docs/v2-upgrade#proxy
Wait a sec...
Are you using PHP or just FastCGI without PHP?
If you're using PHP, you want the php_fastcgi
directive instead of reverse_proxy
, see here: https://caddyserver.com/docs/v2-upgrade#fastcgi
This is still a bug, but before I can fix it I need to know what you're trying to do and how to reproduce it.
# lsb_release -a
LSB Version: :core-4.1-amd64:core-4.1-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-4.1-amd64:desktop-4.1-noarch:languages-4.1-amd64:languages-4.1-noarch:printing-4.1-amd64:printing-4.1-noarch
Distributor ID: CentOS
Description: CentOS Linux release 7.7.1908 (Core)
Release: 7.7.1908
Codename: Core
caddy version
or paste commit SHA)caddy_2.0.0-rc.1_Linux_x86_64
I tried Caddy2 the first time. --> Changed the existing caddy1 caddyfile into a runnable version for caddy2 and caused therefore a panic.
It's a panic. I guess that should be catched before it happens (or be prevented).
please have a look at the first post. :)
I tested it again to tell the steps for reproduction.
reverse_proxy / 127.0.0.1:1091 {
transport fastcgi
}
-->
Caddy 2 passes the headers thru by default, including the Host header, and adds X-Forwarded-For, so you don't need transparent in v2.
Sadly I can't proxy any of my (right now through caddy1 served) websites through caddy2. I guess cookies aren't passed through properly. I guess I just have to learn how to handle the new caddy. Otherwise... when '"including the Host header, and adds X-Forwarded-For"' it should just work fine, right?
Thanks for the added info.
Here comes my mistake. I didn't check properly which of my backends is listening on Port 1091.
What do you mean by this?
Apparently it isn't using PHP. As soon you try to load this Page through caddy2 (while the wrong transport is chosen) it causes a "caddy panic".
I see, so your backend is a FastCGI responder but is not using PHP. So a request, for example, would have an empty path such as /
, right?
Sadly I can't proxy any of my (right now through caddy1 served) websites through caddy2. I guess cookies aren't passed through properly.
Well, the fastcgi transport works different from the HTTP transport. Both send all the headers, but in the fastcgi case it creates an env variable called HTTP_HEADER_NAME like HTTP_COOKIE and that's how fastcgi backends get the cookie information.
What was your working v1 config?
@Pamalosebi I've pushed a fix in 1e8af27 - please try it out! There will be build artifacts you can download momentarily.
Thank you a lot!
I've pushed a fix in 1e8af27 - please try it out! There will be build artifacts you can download momentarily.
I surely will. Probably this is not the correct place for further questions. --> But I may write my question here: https://caddy.community/
Build artifacts: https://github.com/caddyserver/caddy/actions/runs/70010904
As noted in https://caddy.community/t/caddy-v2-and-caddyfile-just-serves-plain-sites/7424/5, confirmed to be fixed :+1:
Hey, since caddy is now almost stable, I wanted to give it a shot. Sadly I felt a little disappointed since many of the old directives were missing. Additionally, I caused a "caddy panic" after 5 minutes:
In the end I had to kill it. The used caddyfile is:
I had to comment out all the stuff which has missing directives or modules since caddy1.
The panic appeared, when the
transport fastcgi
was added.--> btw. is there an alternative to the
proxy { transparent }
from caddy1? I always thought it is very handy. e.g.