Document missing WebAPI 2.8.3 changes in the wiki

[FranciscoPombal]

Originally mentioned in #15152 (comment).

• Provide v1 and v2 infohashes in UI #15097
  • infohash_v1
  • infohash_v2
• Add WebUI reverse proxy source IP resolution #15047
  • web_ui_reverse_proxy_enabled
  • web_ui_reverse_proxies_list
• Announce to all trackers if IP changed #15001
  • reannounce_when_address_changed
• Add connection_speed to advanced settings #14976
  • connection_speed

[FranciscoPombal]

@glassez

What should we do about WebAPI versioning and V2 support? It seems some changes are making their way in that may not be available depending on which libtorrent version the user compiles qbittorrent with. Should we bump the major version? Or just note which features may be or not available depending on V2 support?

[glassez]

@glassez

What should we do about WebAPI versioning and V2 support? It seems some changes are making their way in that may not be available depending on which libtorrent version the user compiles qbittorrent with. Should we bump the major version? Or just note which features may be or not available depending on V2 support?

IMO, while v2 isn't supported officially we have to pretend that nothing related exists in the web API. The web API must be stable (i.e. the same version must have the same set of functions, parameters, etc.).

[FranciscoPombal]

@glassez

So changes like #15097 would remain undocumented until V2 is officially supported, even though it was introduced in 2.8.3?

I have no strong opinion on this, it's up to you and others. But if you do decide to go that route, we should open an issue to specifically track V2-related additions that are to be documented at a later time.

[glassez]

I have repeatedly come up with the idea that we should keep a separate list of WebAPI changes in order to keep it up-to-date. This will save us from confusion with WebAPI versions, and will make it easier to update the documentation. For example:

unknown (unreleased qBittorrent v4.4)
    - Add infohash_v1 field to torrent info
    - Add infohash_v2 field to torrent info

v2.8.3 (unreleased qBittorrent v4.3.7)
    - Add something
    - Add something other

v2.8.2 (qBittorrent v4.3.6)
    - Add something
    - Add something other

[FranciscoPombal]

@glassez How is that different from the existing Changes section? Just add the unknown section.

The issue I'm raising is that now some WebAPI features depend on how the user compiles qBittorrent (libtorrent v1.2.x vs v2.x), and we haven't decided how that should be documented.

[glassez]

@glassez How is that different from the existing Changes section?

It differs in that it is continuously updated. That is, as soon as a change is made, it is immediately entered in the change log. IMO, this looks good not only for the API changes, but also for the main change log. Thus, someone does not need to break their head, analyzing the changes made from the previous release, when a new one is made.

The issue I'm raising is that now some WebAPI features depend on how the user compiles qBittorrent (libtorrent v1.2.x vs v2.x), and we haven't decided how that should be documented.

As I said earlier, this is extremely incorrect if API is unstable in relation to its version. There are several ways to achieve this here, depending on the specific function.

[glassez]

infohash_v1
infohash_v2

What's the problem with they? There is no released WebAPI that has such features.

[FranciscoPombal]

@glassez

It differs in that it is continuously updated. That is, as soon as a change is made, it is immediately entered in the change log. IMO, this looks good not only for the API changes, but also for the main change log. Thus, someone does not need to break their head, analyzing the changes made from the previous release, when a new one is made.

Ah, so you propose making the API changelog a formal part of the repository? Why not just demand that API PR authors update the wiki accordingly as part of the approval process for such a PR?

What's the problem with they? There is no released WebAPI that has such features.

But they do exist, and it is actually possible to query them via the API correct? I assume you just want to leave them undocumented then, and enforce a "if it's not in the API documentation, it is as if they don't exist" policy"? Fine by me, just making sure. But in this case, we really need to make the API changelog a part of the repo or start requiring PR authors update the wiki. Otherwise, a legitimately undocumented API method is indistinguishable from a documented method that we forgot to document, which is confusing for users.

[AbeniMatteo]

What's the problem with they? There is no released WebAPI that has such features.

infohash_v1 and infohash_v2 are merged into master (exposed by /torrents/info) and the release planned is 4.4.0 (web api version 2.8.3).

[glassez]

What's the problem with they? There is no released WebAPI that has such features.

infohash_v1 and infohash_v2 are merged into master (exposed by /torrents/info) and the release planned is 4.4.0 (web api version 2.8.3).

We don't really know what API version will be released with qBittorrent 4.4.0. There may be one or even several more v4.3.x releases before it.

[AbeniMatteo]

I have repeatedly come up with the idea that we should keep a separate list of WebAPI changes in order to keep it up-to-date.
This will save us from confusion with WebAPI versions, and will make it easier to update the documentation.

This change is documented but not yet released.
Having another wiki page or a file in the repo to annotate the changes, while we work on vNext, is a nice solution. When a new qBt is released we can then update the main WebAPI wiki page in one go.

IMO, while v2 isn't supported officially we have to pretend that nothing related exists in the web API. The web API must be stable (i.e. the same version must have the same set of functions, parameters, etc.).

Not a comment but a question: when libtorrent v2 is fully integrated, you will still be able to compile qBt targeting v1.2?

[glassez]

when libtorrent v2 is fully integrated, you will still be able to compile qBt targeting v1.2?

Most likely, this will be possible as a fallback, but personally I would never support both libtorrent branches officially.

[shikasta-net]

I've just managed to get the Reverse Proxy changes (#15047) to work and want to document the instructions that I was missing, to save someone else time, and so they can be added to the wiki. My thanks to @HiFiPhile, for the implementation.

The "Trusted proxies list" needs to be semicolon (;) separated, which is different to the "Bypass authentication for clients in whitelisted IP subnets" list, which is comma separated. The Trusted proxies list, in my case, needed the IPv4-mapped IPv6 address (::ffff:192.168.0.4), not a straight IPv4 address.

In the course of investigation I noted that the log file still records the proxy's IP, because the function just records the remote address header not the X-Forward-For.

[Kariton]

I've just managed to get the Reverse Proxy changes (#15047) to work and want to document the instructions that I was missing, to save someone else time, and so they can be added to the wiki. My thanks to @HiFiPhile, for the implementation.

The "Trusted proxies list" needs to be semicolon (;) separated, which is different to the "Bypass authentication for clients in whitelisted IP subnets" list, which is comma separated. The Trusted proxies list, in my case, needed the IPv4-mapped IPv6 address (::ffff:192.168.0.4), not a straight IPv4 address.

In the course of investigation I noted that the log file still records the proxy's IP, because the function just records the remote address header not the X-Forward-For.

THANK GOD!
NOW I was able to successfully get the correct client IPs!

Well, thanks @shikasta-net!