Revert "Implement Caddy-Sponsors HTTP response header"

[lol768]

1. What does this change do, exactly?

Reverts the recent change to add sponsor headers to HTTP responses. I'm opening this PR here in the hope we can discuss undoing this recent addition. Ref WedgeServer#2 and the HN post.

You're of course free to simply close this PR immediately, but I really hope you'll consider feedback from the community (especially on HackerNews) regarding this change before doing so.

2. Please link to the relevant issues.

N/A

3. Which documentation changes (if any) need to be made because of this PR?

N/A

4. Checklist

• N/A I have written tests and verified that they fail without my change
• N/A I have squashed any insignificant commits
• N/A This change has comments for package types, values, functions, and non-obvious lines of code
• I am willing to help maintain this change if there are issues with it later

[CLAassistant]

All committers have signed the CLA.

[captncraig]

My two cents - acknowledging a couple of things up front:

• Matt does not owe us anything.
• He is free to do as he chooses with this repo.

That being said...

Why does the header matter?

I'm not fussed about the transfer size or the security implications, or anything like that. For me, it is all about control. I feel responsible for every piece of content served on a site. I feel that I should be able to control the complete end-user experience.

You can downplay it all you like, but http headers are a part of your user experience, particularly if you have an api that uses headers for communicating other data.

Now, the web server has decided that it will add headers, and I have no choice in the matter. Caddy has not been shy about enforcing its opinions on users in the past. This though, feels a particularly arbitrary. I appreciate things like "secure by default", and "the config language should not be sentient", because they are key to caddy's core identity. This is not. This is the first time that I have felt like caddy physically will not let me control an aspect of my site that I feel I should have full control over. And for no particularly good reason.

Furthermore, I feel like the header, in its' current form is somewhere between confusing and an outright lie:

This free web server is made possible by its sponsors: Minio, Uptime Robot, and Sourcegraph

Which server? To an uninformed observer, it looks like those services are sponsoring each and every site served by caddy. This is obviously not the case. If someone sees that header on a paid site, are they going to be confused at why it says it is free? Are these sponsors really ok if really offensive content is displaying their names as primary benefactors? Did they really sign up to be a source of controversy in your open source project?

I've seen stuff like "Why does it matter if nobody ever sees it?" used to defend this a lot today, and I kinda feel like that is a good argument in the opposite direction as well. What value can it possibly give? Is that benefit really worth taking a stand over?

You are allowed to sell this

I do not object to you trying to monetize caddy. You gotta do you, and I respect that. If the caddy website, and your build infrastructure are tools to use for advertising your business and trying to make sales, so be it.

I am a little bit uncomfortable with the situation though. I've been ok submitting plugins to the build server since it was the de-facto way to distribute plugins. The more it feels like working for free for a faceless corporation to profit off of, the less fun it is. I'm not saying my fun needs to be your primary goal, but that is the spirit that attracted me to this project in the first place.

"Just build it yourself"

I don't feel like that answer is really a good-faith response to the backlash on this. How exactly are we intended to change that behavior?

sed -i -e '/sponsors/d' $GOPATH/src/github.com/mholt/caddy/caddyhttp/httpserver/server.go seems like a pretty trivial thing to make a fork over, but also a bit too brittle to feel comfortable building infrastructure to automate. Can you throw us a little bit of a bone on this one? A few ideas:

• Inject the relevant code only for builds on the build server
• Have a build tag no-sponsor that will disable the behaviour without having to hack the code up.
• Have a cli flag like -thankYouVeryMuchMinio,UptimeRobot,AndSourcegraph that will disable it. Make that availible in all builds.

In conclusion, I really can't jump so far as others have to say conclusively that "This is a huge mistake and you shouldn't have done it". But the whole affair has made me extremely uneasy for a variety of reasons that are really hard to put a finger on.

[captncraig]

If a plugin to reverse this behaviour showed up on the build server, would you remove it, or allow it to stay?

[pepa65]

Caddy binaries are now no longer Free software, they are adware or commercial. The source is open, but the build/ecosystem is complex. Was the build system also closed??

Very sad to see a fantastic project being irreversibly compromised. Many people will have to move away now from Caddy, and we can no longer unequivocally recommend it.

Even if the sponsor header is modified by a plugin, the license is still problematic.

[abperiasamy]

Showing advertisements in the HTTP response header field is an annoyance. Please remove "Minio" from the header.

[Zarthus]

I would like to doubly emphasize the point @captncraig made regarding the wording. Even if the final conclusion is to not alter this header's behaviour, it should at least change the text to emphasize that it is not about the website they are currently viewing, but about the webserver software. This is definitely worth discussing as a separate issue entirely.

[mholt]

I want to clarify something for the record, since this issue has already been brought out here to the public in the comments above.

Weeks, and then days, before we implemented this header and released the change, we notified our sponsors in an invite-only Slack channel exclusively for sponsors (including using a channel-wide @-mention at one point) that this is what we were planning, and encouraged any of them to freely give their feedback if they had any questions or concerns either way (screenshots attached). We received no responses from any sponsors, so we proceeded forward with the change. It simply seems our message didn't reach them.

Anyway, we're sorry to see Minio go, as we think their team is great and so is their product. We're also sorry for any miscommunications. This whole thing is too bad.