It's fairly easy to check for yourself, but with local builds on a desktop CPU without QAT, compressing a 150MB JSON input, with igzip and minigzip (from zlib-ng) both producing a smaller output than gzip, gzip needs 1.187s, minigzip needs 0.665s, and igzip needs 0.313s.
immune system cells actually share a lot of the same receptor systems as neurons do, and these systems end up influencing each other to significant degree, both ways.
NULL is more of a declaration that 'there is no value', than mathematical value on its own. if you compare NULL with something you don't get false, you get NULL (which is often considered same as false).
some implementations carry the same "uncomparable" logic when checking for unique constraints, while others drop the ball here.
programming language wise, it's kinda like null pointer or float NaN, both of which are also occasionally complained about, eg. indexing maps by float values can do bogus things in case of NaNs.
Not providing verification would seem like a nearly fatal flaw would it not? If one cannot pass around IPFS urls and ensure that the content returned is the same for all users, it would make a great way to MiTM a target.
Which AFAIK Apple does not use. I have RCS enabled on my Android phone but it only works to other Android users who have a compatible phone that also has RCS. Still does not resolve the OP's issue that Apple refuses to send/receive messages to/from other vendors' devices unless it is via SMS/MMS. It's a sad state of affairs indeed.
I’ve seen it posted multiple times on this very forum that carriers have not done a good job rolling this out. How is this actually going over in Android-land?
In Australia it's been on Telstra for a bit. I got it working on Optus last year. I don't know what happens to other companies running over the Telstra or Optus networks though.
You definitely shouldn't strip left side of header, as space preceding that is syntax for header splitting over multiple lines at least in email. Not sure if this applies to http though, but some parsers may do that anyway, and some don't.
Just shows how easy it is to be wrong by being lazy with http parsing.
For most of us that means an untrusted cert, and hence a browser warning, but that's equivalent to the browser padlock icon when browsing http (and arguably safer).
Plus, if you are browsing or publishing using plain ip addresses you are already outside the "regular behaviour" so users doing that will be happy to click through.
However this subthread is irrelevant to the main thread. The https/http question is unrelated to the dns question, since dns applies to both equally.
