[Misc] Under-the-hood fixes, improvements and tests (pt 2)

[dirkf]

Boilerplate: own/yt-dlp code, bug fix/improvement

## Please follow the guide below

• You will be asked some questions, please read them carefully and answer honestly
• Put an x into all the boxes [ ] relevant to your pull request (like that [x])
• Use Preview tab to see how your pull request will actually look like

---

Before submitting a pull request make sure you have:

• Searched the bugtracker for similar pull requests
• Read adding new extractor tutorial
• Read youtube-dl coding conventions and adjusted the code to meet them
• Covered the code with tests (note that PRs without tests will be REJECTED)
• Checked the code with flake8

In order to be accepted and merged into youtube-dl each piece of code must be in public domain or released under Unlicense. Check one of the following options:

• Except for code taken from yt-dlp for which either this or the below has already been asserted, I am the original author of this code and I am willing to release it under Unlicense
• I am not the original author of this code but it is in public domain or released under Unlicense (provide reliable evidence)

What is the purpose of your pull request?

• Bug fix
• Improvement
• New extractor
• New feature

---

Description of your pull request and other information

This PR encapsulates various under-the-hood fixes, improvements and tests.

• Process Content-Encodings according to RFC 9110:
  • support nested encodings
  • support br encoding, if Brotli package is installed (pip install brotli, "Only Python 2.7+ is supported." -- Only?)
  • support 'compress' encoding, if ncompress package is installed (pip install ncompress, "Requires: Python >=3.8")
  • change: the response Content-Encoding header has only unprocessed encodings, or is removed if all encodings were decoded
  • change: the value in the Content-Length header is the decoded length
  • zlib is used for both deflate and gzip decompression (except for Jython which doesn't support this in 2.7.1 for reasons not investigated)
  • some elements taken from [core] Fix HTTP redirect handling yt-dlp/yt-dlp#7094: thx @coletdjnz.
• Rework URL path munging for ., .. components ( problem with double-dot segments (/../) after the hostname yt-dlp/yt-dlp#3355):
  • revise e8de54b as part of utils.YoutubeDLHandler
  • using this, also process Location header for redirects
  • use the static (test_utils) and network (test_http) tests from [networking] Remove dot segments during URL normalization yt-dlp/yt-dlp#7662.

[pukkandan]

Has this ever been observed in the wild? I'm against adding a whole new dependency for a use case that's never encountered.

[pukkandan]

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Encoding indicates compress has been deprecated for decades

[dirkf]

It says:

... this content-encoding is not used by many browsers today ...

Not by Mozilla, eg. One guy on the Web seemed to want it, though it's hardly a yt-dl application and it was indeed more than two decades ago.

However as compress is in RFC 9110 and easy* to support, I included it.

It's a fairly trivial point since encoding is negotiated and compress is arguably a different case from br (Myspace vs Instagram). We would never have seen a bug report if some site offered compress but not gzip or deflate. You could surely be absolved if yt-dlp failed to reflect this feature, even given the slicker dependency system.

Separately, I wonder what sites do today if the client says Accept-Encoding: identity (so no encoding). Would that provoke/alleviate fingerprinting issues?

* Considering negotiation, the PR doesn't advertise any optional encodings, though, since I forgot to include that change.