The article says they are trying: "The IPAct effectively prohibits ISPs from talking about much of this, which makes it difficult to verify the details"
I'm not sure if the "URL" column in a table in the article is supposed to contain URLs. In the example it only has domain names. I don't think full URLs can be obtained from SSL/TLS connections.
I assume it's because to lay people don't distinguish a domain name, an FQDN, eTLD+1, URL, "web address", URI, etc. and I'm sure that it's just as frustrating in any other discipline with a complicated vocabulary.
#Appendix isn't sent anywhere, your browser only needs that locally
The path /some/directory and the query ?someParameter=Value are encrypted using keys which should be known only to the browser and server, today in most cases the keys are random and will be forgotten soon afterwards
The scheme https is implied by your browser's connection to an HTTPS web server. Modern browsers also explicitly transmit ALPN requesting h2 (HTTP/2) if available in their ClientHello, this will not be encrypted today.
The server name www.example.com is somewhat implied by your browser's connection to an IP address for this server. Any browser that still works in 2021 explicitly transmits the SNI requesting this name, so as to enable Virtual Hosting which offers multiple distinct web servers on a single IP address. SNI is also in the ClientHello and thus not encrypted.
The full server name will also be looked up by the browser in DNS. In many cases this means an unencrypted UDP query for that name, and this may in turn trigger a query for example.com, and in theory at least, com itself because DNS is hierarchical and the hierarchy may need to be discovered.
You can secure some of this last step by using any of the DPRIVE technologies, including DNS over HTTPS (DoH) or DNS over TLS (DoT) and some day DNS over QUIC (DoQ). Eventually DPRIVE might also secure the recursion, but even today if snoopers can see that Google's DNS service asked about example.com that does not pin down who wanted them to do that, let alone why.
If you've secured DNS, this will pave the way for ECH, a forthcoming standard to Encrypt the ClientHello. It is likely that popular browsers will begin just doing ECH (silently enabling it for at least some users) in the next year or so, but right now it isn't quite finished.
Even with an Encrypted ClientHello, the IP gives away roughly who you connected to. The Internet Archive, the Fox News web site, and Wikipedia have no interest in sharing IP addresses with Porn Hub so as to throw off snoopers who are wondering roughly what you're doing. On the other hand, Encrypted ClientHello would hide whether you're looking at the German Wiktionary or the English Wikipedia page about the Hitler Youth, and it would mean there was no longer a privacy advantage to a site using directory prefixes to categorise things versus using server names.
The set of IP addresses you connect to correlates with the domain connected to and the amount of data transferred correlates with the exact URL being loaded.
I'm not sure if the "URL" column in a table in the article is supposed to contain URLs. In the example it only has domain names. I don't think full URLs can be obtained from SSL/TLS connections.