4 ms·

> Why's that? (And even among your technical visitors, how many of them actually inspect the response headers?) I dislike this for a few reasons. Firstly, it h

by lol768 9y ago

> Why's that? (And even among your technical visitors, how many of them actually inspect the response headers?) I dislike this for a few reasons. Firstly, it honestly comes across as petty. I'm using the server for personal reasons, it's for a non-commercial site which I don't make money off. I don't display ads, and suddenly I'm now being forced to serve ads to my visitors. The medium of delivery is utterly irrelevant to me. Secondly, it makes it more difficult to take steps to make it less obvious which web server is being used. I'd do this to make it slightly more difficult for script kiddies looking to exploit recent vulnerabiltiies - not because I think security through obscurity is a good idea. > It's good to know that price isn't the bottleneck, then. Does it make any difference to know that commercially-licensed Caddy builds don't have that header? No. The point is, you've annoyed someone who liked your software, used it for personal use (costing you nothing) and would've happily recommended it to colleagues.

JosephLark 9y ago
> No. The point is, you've annoyed someone who liked your software, used it for personal use (costing you nothing) and would've happily recommended it to colleagues. This is worth keeping in mind. Personally, this change is putting me off Caddy to the point that I might stop using it for personal sites. The big feature for me - instant LetsEncrypt TLS certificates - can be done on other servers now fairly simply. So the end result might be that I no longer use Caddy, which means I'll no longer have it in mind for commercial projects I work on.
- djsumdog 9y ago
  I have pretty much the same reaction. I was considering moving some stuff to Caddy, but looking at this, I'd need to create my own build pipeline to keep rubbish like this out. No thanks. I'll use tools that give me the options of turning things like this on/off without having to compile my own copy.
- tylersmith 9y ago
  I was pleasantly surprised at how quickly I was able to rip out Caddy and replace it with nginx and Traefik (in different cases), even with the LE automation. It shouldn't be much of a burden to move your person projects I don't think.
- folago 9y ago
  Seconded. This is also how I felt reading the news.
mholt 9y ago
> Secondly, it makes it more difficult to take steps to make it less obvious which web server is being used. I'd do this to make it slightly more difficult for script kiddies looking to exploit recent vulnerabiltiies - not because I think security through obscurity is a good idea. I thought about this as well, but I'm not convinced that hiding the Server header or anything like unto it is really that beneficial. Most exploits are automated anyway. And if it becomes common to hide or remove the Server header for Caddy instances, then guess what becomes its new signature? > used it for personal use (costing you nothing) This unfortunately isn't true. It costs a LOT of time and effort to maintain the build infrastructure and the Caddy project itself, even if its users don't make a profit from it.
- warrenm 9y ago
  >> used it for personal use (costing you nothing) > This unfortunately isn't true. It costs a LOT of time and effort to maintain the build infrastructure and the Caddy project itself, even if its users don't make a profit from it. Yes - it is true. The incremental cost for every additional Caddy install is 0 (or, as close to 0 as you can calculate for bandwidth charges). So ... no. It does not cost you anything for an additional user to run Caddy. It is a sunk cost for any given new development - whether one person runs it, or millions. But instead of realizing this, you've now put-off a vast swath of potential users. Bad form.
- Veratyr 9y ago
  > I thought about this as well, but I'm not convinced that hiding the Server header or anything like unto it is really that beneficial. We as users don't believe that's your choice to make. > And if it becomes common to hide or remove the Server header for Caddy instances, then guess what becomes its new signature? This only applies if Caddy is the only server that does this, which is not the case.
- seanwilson 9y ago
  > I thought about this as well, but I'm not convinced that hiding the Server header or anything like unto it is really that beneficial. Most exploits are automated anyway. It probably doesn't help much but it can't hurt. Some servers send back a "Server" header that tells you the OS being used with the Apache and PHP version up to the minor version number for example. There's no benefit to leaking this information and it's potentially useful to an attacker even if only marginally so why risk it?

by lol768 9y ago

JosephLark 9y ago

> No. The point is, you've annoyed someone who liked your software, used it for personal use (costing you nothing) and would've happily recommended it to colleagues. This is worth keeping in mind. Personally, this change is putting me off Caddy to the point that I might stop using it for personal sites. The big feature for me - instant LetsEncrypt TLS certificates - can be done on other servers now fairly simply. So the end result might be that I no longer use Caddy, which means I'll no longer have it in mind for commercial projects I work on.

djsumdog 9y ago
I have pretty much the same reaction. I was considering moving some stuff to Caddy, but looking at this, I'd need to create my own build pipeline to keep rubbish like this out. No thanks. I'll use tools that give me the options of turning things like this on/off without having to compile my own copy.
tylersmith 9y ago
I was pleasantly surprised at how quickly I was able to rip out Caddy and replace it with nginx and Traefik (in different cases), even with the LE automation. It shouldn't be much of a burden to move your person projects I don't think.
folago 9y ago
Seconded. This is also how I felt reading the news.

mholt 9y ago

> Secondly, it makes it more difficult to take steps to make it less obvious which web server is being used. I'd do this to make it slightly more difficult for script kiddies looking to exploit recent vulnerabiltiies - not because I think security through obscurity is a good idea. I thought about this as well, but I'm not convinced that hiding the Server header or anything like unto it is really that beneficial. Most exploits are automated anyway. And if it becomes common to hide or remove the Server header for Caddy instances, then guess what becomes its new signature? > used it for personal use (costing you nothing) This unfortunately isn't true. It costs a LOT of time and effort to maintain the build infrastructure and the Caddy project itself, even if its users don't make a profit from it.

warrenm 9y ago
>> used it for personal use (costing you nothing) > This unfortunately isn't true. It costs a LOT of time and effort to maintain the build infrastructure and the Caddy project itself, even if its users don't make a profit from it. Yes - it is true. The incremental cost for every additional Caddy install is 0 (or, as close to 0 as you can calculate for bandwidth charges). So ... no. It does not cost you anything for an additional user to run Caddy. It is a sunk cost for any given new development - whether one person runs it, or millions. But instead of realizing this, you've now put-off a vast swath of potential users. Bad form.
Veratyr 9y ago
> I thought about this as well, but I'm not convinced that hiding the Server header or anything like unto it is really that beneficial. We as users don't believe that's your choice to make. > And if it becomes common to hide or remove the Server header for Caddy instances, then guess what becomes its new signature? This only applies if Caddy is the only server that does this, which is not the case.
seanwilson 9y ago
> I thought about this as well, but I'm not convinced that hiding the Server header or anything like unto it is really that beneficial. Most exploits are automated anyway. It probably doesn't help much but it can't hurt. Some servers send back a "Server" header that tells you the OS being used with the Apache and PHP version up to the minor version number for example. There's no benefit to leaking this information and it's potentially useful to an attacker even if only marginally so why risk it?