Hacker News new | ask | show | jobs
by r3trohack3r 1341 days ago
This doesn’t sound like bullshit to me. Serving a static text file that is primarily used by applications is not in line with their terms of service.

Cloudflare provides a significant service to the free and open web by subsidizing the hosting costs of static content for websites. They give that away for free under what appears to be reasonable terms.
4 comments
GekkePrutser 1341 days ago
But it is web content, really. A txt file renders fine in every browser.

Many websites also push text through HTML as part of AJAXy stuff. If they actually enforced this for all sites, their service would no longer be usable.

link
prvit 1341 days ago
Movies will render in browsers just fine too, doesn’t mean that cloudflare will allow you to cache them.
link
vifon 1340 days ago
Their documentation seems to disagree. https://developers.cloudflare.com/cache/about/default-cache-...
link
renewiltord 1341 days ago
Sadly, despite my arguments in the same direction, Cloudflare refuses to host a base64 encoding of the new Flubber.
link
yellowapple 1341 days ago
I can think of few things more static than a .txt file.
link
r3trohack3r 1341 days ago
You're missing the point. The service cloudflare donates isn't free. That is the whole point of EasyList’s post. There are plenty of comments on this submission doing back of napkin math to find a reasonable monthly cost for hosting that text file. If you want to donate that bandwidth - go for it.

But the comments here about Cloudflare’s ToS read a lot like folks feeling entitled to getting bandwidth for for free. Cloudflare is providing a very specific service for free, and it does a lot of good.

It would be great if Cloudflare decided to donate. But I’d re-evaluate your stance if you’re feeling entitled to their resources.

link
yellowapple 1341 days ago
> You're missing the point.

You're missing the point. If Cloudflare's issue is with bandwidth, then they should say so and leave it at that, not conjure up this pathetic excuse about .txt files somehow not being "web content". Does wrapping that data in <html><body><pre> </pre></body></html> magically fix the bandwidth issues?

link
megous 1341 days ago
Even just plain text file without any tags is a valid HTML 5 file. You don't need any tags. <html> and <body> are implied.

All you'd need is a <pre> tags or <style> somewhere if you'd want it rendered not just as one large paragraph.

I guess you may need a <!DOCTYPE html>

link
kevincox 1341 days ago
Just making a file valid HTML doesn't make it "web content". This file is being fetched by an application, not being viewed by a user.

I'm not sure this is the most reasonable rule but there are definitely some benificial aspects to it. For example the load on human-viewed content is limited by how often people want to view it. Not how often their browser wants to redownload it.

link
yellowapple 1341 days ago
> Just making a file valid HTML doesn't make it "web content".

By Cloudflare's rationale it does.

> For example the load on human-viewed content is limited by how often people want to view it. Not how often their browser wants to redownload it.

Bandwidth is bandwidth. If 100,000,000 humans want to download a 10KB text/html page v. 100,000,000 programs wanting to download a 10KB text/plain file, both within the same time period, then that's going to be the same degree of load on Cloudflare's end.

link
mindslight 1341 days ago
Actually you're missing the point. It doesn't seem like many people are condemning Cloudflare for not serving a bandwidth-heavy file for free (FTA: "CloudFlare does not allow non-enterprise users use that much traffic").

Rather what's being condemned is this nonsense customer service characterization of a text file as somehow not "web content". Easylist.txt is a data file that could just as easily be in JSON (and be larger). Furthermore, as it stands easylist.txt actually looks like it's a valid text/html file, as browsers generally don't insist on <html>/<body> tags. So from both directions it seems like the customer service drone has thrown out this nonsense just to short circuit having to do their job.

link
r3trohack3r 1341 days ago
I like the HN approach of taking a charitable interpretation of their message.

Clearly EasyList lived on their free tier for a long time without interruption. Only when they used excessive bandwidth did ToS enforcement happen. When they reached out for support, the support agent rightly pointed out that this isn't a website file.

Reading the ToS, the support agents message appears to be correct. Text files are fine (as is pretty much any format) as long as it isn't the main focus of the HTTP server Cloudflare is fronting. Robots.txt would be fine, turning the list into XML or HTML would not be fine. In this case, the text file isn't there to support the web content of Easy List - it's distributing a text file to applications.

The agent could have added additional context but their message is valid.

link
mindslight 1341 days ago
You're still conflating "free tier" with "not a web file". According to the article, they are separate issues and Cloudflare wouldn't be willing to host easylist.txt even on a paid plan.

Meanwhile -

1. easylist.txt is used by every single web page I visit. So the overall purpose argument fails.

2. Web pages commonly use non-directly-renderable data files in formats like JSON or XML, so the file purpose argument fails.

3. Text files are and continue to be one of the major formats displayed by browsers. So the file type argument fails.

4. The size of the file is in line with other files cached by Cloudflare. So that argument fails.

If the Cloudflare support rep said "we just don't feel like doing business with you", that would be a different thing. But instead they're throwing out some arbitrarily-framed unfalsifiable reason as if it's a logical justification. And no, customer service drones and corporate policies don't deserve a fundamental benefit of the doubt, per contra proferentem (ambiguous terms should be construed against the drafter). It's impossible to know what they actually mean here besides "we don't like it", and that is the problem.

link
manigandham 1341 days ago
But it's not JSON or HTML. And it's not meant for browsers. It's clearly a dataset as a text file and not meant as "web(page) content". What's nonsense about that when it's completely accurate?
link
thayne 1341 days ago
How is it any different from a json file used by a web app (or mobile app, or desktop app)?

And there is no reason a web app couldn't read data from a txt file instead of a json file.

link
manigandham 1341 days ago
It's not for displaying a webpage but to power a separate application. Just because you can serve any kind of file over HTTP doesn't mean it's for serving a website. There's a reason Cloudflare doesn't allow large video files either - even though that probably counts even more as "web content".

This is a very straightforward interpretation of the terms and it's strange to see such pushback based on a pedantic technicality when it's clear what the file is being used for.

In fact, if this was the opposite situation and some automated rule was involved in isolating this file, I expect the same people would then want human intervention to clear up the difference based on the context.

link
yellowapple 1341 days ago
> And it's not meant for browsers.

It literally is - specifically, for extensions thereof.

link
3np 1341 days ago
oh it's for browsers all right
link
martimarkov 1341 days ago
A text file is a website file and that is what annoyed me in that support reply. The web is not just html, css and JS.

But in order to make the support eng do his job I need to add a .html extension to it?? Would that be considered a website file?

link
Fnoord 1341 days ago
Interestingly, one could host this on a WWW frontend for Git. Then you'd only need to download (say a daily) diff. Why download the entire list when you can match checksum?
link
m-p-3 1341 days ago
So if the text was embedded in a static webpage that the client had to parse locally, that'd be okay?
link
Terretta 1341 days ago
Welcome to robots.txt:

https://developers.google.com/search/docs/crawling-indexing/...

link