The part of this that's most likely to fail at some point is the "http://".
The part of this that's most likely to fail at some point is the "http://".
Even if you interpreted the bet generously to allow for a browser to render the content using JavaScript, if I understand the bet correctly, the condition of working with a command-line tool like curl would fail.
I can see how other interpretations are possible, but I don't see anything especially generous about mine. I'm not "allowing" anything: To make a judgement you have to pick a web browser to try it with, and you'd probably pick the most popular one, in the most popular configuration, that seems the most fair. If that web browser happens to execute Javascript when you navigate to an URL, then that's just how it is.
(Though, that said, some approaches to rendering sites via JavaScript would still have that text in the initially downloaded HTML file as JavaScript data.)
As for the "or", I read it as "doing either X or Y must", not "either X must or Y must (not necessarily both)", but yeah, I can see either interpretation being valid.
Now I'm a human slave copying text from web browsers to chat windows to get around JS rendering bullshit.
But I do the same as GP, just on the receiving side. That is, reaching out for help to baby eldritch entity, because that's healthier for my mind than dealing directly with the unspeakable horrors that half the websites are today. The industry has lost its collective mind in pursue of profit and control, and that was long before the thousand-mask wearing shoggoths became our daily consorts.
> A 301 redirect from www.longbets.org/601 to a different URL containing that text would also fulfill those conditions.
I assume this would cover the HTTP->HTTPS redirect scenario.
In particular, the automatic upgrade feature in modern browsers is based on several heuristics rather than explicit configuration like HSTS, so there's always a bit of room for breakage there. For example, they don't even check if the server returns a 301 redirect, which can be problematic if the server wants to redirect to HTTPS on a different host/port or make some changes to the path.
They're not going to get any cleverer than they are now. In October we'll finally be done with heuristics or central databses of https-first websites used by the various browsers or the half a dozen of headers that you must dance around to get the upgrade to work securely and reliably. They will just default to https first.
https://blog.google/security/https-by-defau/
Yes this is about Chrome, but all others will follow.
And in any case, at some point after browsers start doing that, I will be unsurprised if some further conditions prevail that provide reason for web servers to stop listening on http at all.