4 ms·
That would be fine because then CF could replace that HTML with their "Checking your browser before accessing" content. What's the app going to think of that th
by kenmacd 4y ago
That would be fine because then CF could replace that HTML with their "Checking your browser before accessing" content. What's the app going to think of that though?
- yellowapple 4y ago> That would be fine because then CF could replace that HTML with their "Checking your browser before accessing" content. They could do that anyway by putting up the "Checking your browser before accessing" page and redirecting to whatever file was being accessed. There's precisely zero need to outright modify the HTML files being served to inject such checks.
- kenmacd 4y agoNo they couldn't. If you replace a .txt file with random html data bad things are going to happen. Tell me, how does CF put a 'Checking your browser' page in my `wget https://easylist.to/easylist/easylist.txt https://easylist.to/easylist/easylist.txt`
- yellowapple 4y ago> If you replace a .txt file with random html data bad things are going to happen. Bad things are already happening. Random HTML data is no less useful than no data at all. > Tell me, how does CF put a 'Checking your browser' page in my `wget https://easylist.to/easylist/easylist.txt https://easylist.to/easylist/easylist.txt` By serving the HTML instead (with JS that does whatever checks and then redirects to the intended resource), and if the client can't cope with that, then tough shit; the absurdity of such arbitrary evaluation of whether or not clients are sufficiently browsery to be worthy of consuming bandwidth aside, ain't "only browsers directly navigating to this will be able to cope with this and gain access" exactly the point of using such JS-based client checks in the first place?