Caddy Commercial Sponsor Header clarification?


(George) #1

Hi just read the announcement for Commercial Caddy licensing and the requirement for the Caddy-Sponsors HTTP header being required/used. I need clarification,

  1. Does this only apply to the official provided/downloaded binaries and is not a requirement if building via source compile ourselves ?
  2. Or does this Caddy-Sponsors header requirement also extend to self built source compiled Caddy binaries ?
  3. Is there a limit to size of the header as you add more sponsors ?
  4. I am testing and evaluating Caddy for integration into my Centmin Mod LEMP stack installer which is open source and free, so distributing Caddy via custom integration into my LEMP stack installer would be considered commercial or personal use ? What if my Centmin Mod LEMP stack users usage is commercial ? How do I deal with Caddy distributed this way ? I DO NOT have any info as to what my users use my LEMP stack for whether it’s personal or commercial. The integration doesn’t modify any Caddy source code. It’s just scripted integration for automatic site vhost creation via shell based script cli command line or shell based menu so it eventually generates domain vhosts which would work with several planned web server integrations - nginx and later, openlitespeed, litespeed, apache 2.4, caddy and/or h2o. So end user can generate a site vhost once and be able to choose which web server they want to use which would share a common site account structure/web roots etc. Also Haproxy is planned too so technically can have web sites running different backend web servers eventually.

The concern I have is due to performance as there’s known performance overhead with Caddy as you start adding more HTTP headers to your site - benchmarks at https://caddy.community/t/any-performance-overhead-as-you-add-more-headers-under-http-2/403. Have you looked at the performance overhead as you continue to add new sponsors and increase the size of the Caddy-Sponsors header ?

I would rather put in the HTML footer of a Caddy powered web site, a Powered by Caddy text/logo then have additional HTTP headers reduce overall web performance over time. Just my 2 cents :slight_smile:

Currently I see

curl -I https://caddyserver.com/blog/accouncing-caddy-commercial-licenses
HTTP/1.1 200 OK
Accept-Ranges: bytes
Caddy-Sponsors: This free web server is made possible by its sponsors: Minio, Uptime Robot, and Sourcegraph
Content-Length: 0
Content-Security-Policy: style-src   'self' https://fonts.googleapis.com;                                         script-src  'self' data: https://www.google-analytics.com https://checkout.stripe.com;                                          img-src     'self' data: https:;                                          font-src    'self' data: https: blob:;                                          media-src   'self' https:;                                      connect-src 'self' https:;                                      object-src  'none';
Content-Type: text/html; charset=utf-8
Etag: "ow83jscod"
Last-Modified: Wed, 13 Sep 2017 14:43:04 GMT
Referrer-Policy: no-referrer-when-downgrade
Server: Caddy
Strict-Transport-Security: max-age=31536000
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-Xss-Protection: 1; mode=block
Date: Wed, 13 Sep 2017 16:40:08 GMT

(Matthew Fay) #2

Hi @eva2000, I’m going to try to answer these for you.

That’s correct. The source code is licensed under the Apache License 2.0, as seen here: https://github.com/mholt/caddy/blob/master/LICENSE.txt

You may make any changes you like to the source code. There are some caveats under certain circumstances that may require you to announce attribution and changes in your distribution. If you intend to distribute for commercial purposes, I’d read and understand the license first.

Nope, you’re all good.

HTTP headers don’t have an explicit limit on line length, and I think it’s unlikely to ever cause a problem. Certainly I don’t believe it’s on anyone’s mind to establish any limit, no. At the moment the string is pretty small: https://github.com/mholt/caddy/blob/ad973f1d125d4da9ba8bc21448dcd3de3fe79cbe/caddyhttp/httpserver/server.go#L346-L347

But I can’t comment on whether or not the developers have looked specifically into the performance hit.


(George) #3

Thanks @Whitestrake i added a 4th question above just now too regarding commercial vs personal licensing.


(Matthew Fay) #4

No worries, let me give this one a shot too.

The short answer is yes, go for it. Here’s the relevant part of the Apache license that grants the right to redistribute, based on a few conditions:

What your users use your software for is up to them, and they’ll have to meet the same requirements for distribution (it’s their responsibility to observe the license). But usage of your free software, for commercial purposes, is fine.


(George) #5

cheers @Whitestrake for clarification. Will definitely will give that license a read :slight_smile:


(Matt Holt) #6

Yep, as long as you build from source yourself, you’re bound to the Apache license and not the EULA. If you download Caddy binaries from the website, the EULA applies.


(Matthew Fay) #7

Not a bad idea. As far as licenses go, it’s definitely very readable and understandable, and it’s not a very long document.


(George) #8

@matt thanks for the clarification. Makes things clearer :slight_smile:

Source compiles will make things interesting for performance and load/scalability tests as it also opens up a lot of options for compiler (Clang vs GCC) and compiler options though I haven’t done any Caddy source builds as yet so not sure if they’re applicable with regards to Caddy?


(Carl George) #9

@eva2000 Based on the name Centmin, I’m guessing that your project is CentOS based. If that is the case you could use my copr for caddy once you update to CentOS 7.4 (due out any day). That copr is where i’m working out the kinks to submit the package to Fedora and EPEL.


(George) #10

Tried my hand at source compile but guess there’s a bug right now https://github.com/mholt/caddy/issues/1843 :slight_smile:

@carlwgeorge Yup CentOS focused. I remember reading about your repo :slight_smile: You’re building your own caddy binary from source and just packaging the binary into an RPM ?

What happens with all the Caddy plugins, when building from source ? or installing from your YUM repos ?


(Carl George) #11

Yes, along with a systemd unit file and a directory structure for system wide config files (/etc/caddy/caddy.conf and /etc/caddy/conf.d).

Since the plugins are compiled in, the plugin decisions have to be made for the whole repo. At the moment I’m enabling all the dns providers (go get in the spec file, which won’t be allowed in Fedora). When I initially submit it to Fedora I’ll probably have all plugins disabled, then re-enabled select ones once I can submit the relevant go library to use as a build dependency.


(Michael Adams) #12

@Whitestrake & @matt : thank you for clarifying things thus far. Next question: I know you guys gotta keep the lights on, but $100/mo per every 2 instances seems rather steep. What’s the incentive for all of us to help document and develop code for this? And couldn’t you take an approach like Nginx does for their web server? https://www.nginx.com/products/nginx/


(Matt Holt) #13

Help me understand where you’re coming from. This particular price point equates to $50/instance. NGINX is $200/instance. Is that not steep? You want us to take an NGINX approach yet NGINX is 4x the cost, and you say ours is already too high.

See, I get mixed signals here.


(Norman Eckstein) #14

I agree with @unquietwiki $100 USD per month is far too expensive.

This project gained such a heavy traction because if was open source and free and now there is suddenly the “money-train”.

You should at last offer cheaper licenses for small businesses, like a fair-priced 60 $ per year license bound to a single developer or something like that.

How many customers will you get with $100 per month and imagine how many customers worldwide you will have with $60 per year.


(George) #15

@matt another question with regards to HTTP Sponsor header. Some 3rd party proxy services (cloudflare, sucuri, incapsula or CDNs etc) or reverse proxies might strip out the Caddy HTTP sponsor header where the end user doesn’t have complete control over it. How would we deal with those situations ?


(Michael Adams) #16

Hey @matt sorry for not being fully clear on the comparison. They offer a distinct, separate product. Asking $100/mo on an honors system, is both confusing and not going to achieve your desired income stream. @ITSecMedia suggested a better price point for a single-dev. Also, what about use cases? My own uses cases aren’t for web-dev; they’re for hosting other open-source apps, or connecting to existing servers. I’m not running commercial web-hosting, or paid services.

(ponders) Here are some viable points of separation…

  • Anyone can make a website / throw on some HTML / etc.
  • Certain open-source and commercial applications need things like the proxy and fastcgi modules. This is my current use case; and since you appear to control those modules, would be ideal for the lower price-point.
  • I think you also control the load-balancer. I think we all can agree that having a need for load-balancing indicates mission-critical & commercial viability. This is where you can soak the bigger fish.

(Mark Hanford) #17

It is somewhat disappointing that we’ve spent the last 15 years trying to eradicate tech-identifying headers from leaving our networks, and here we have a “secure by default” service doing just that, and explicitly and intentionally.

Have we already forgotten all the fuss caused because IIS was putting MS headers in the output?


(Esoteric Tweeter) #18

The header has been removed : https://github.com/mholt/caddy/pull/1866


(Mark Hanford) #19

lol then I withdraw my indignation :wink:


(Matt Holt) #20

Tell me how a header is a security exploit? (And don’t say "because it reveals the server that’s running – there are more serious ways to fingerprint a server, and most exploits are automated these days anyways.)