It should always “report”, as in the API returns the speed.
The UI just does not always show it.
Is this what you see as well?
That looks like the transfer has not started yet?
There are both the original/legacy “single transfer” fields: BackendSpeed and the new ActiveTransfers field. Then new field shows all active transfers and their speeds, where the original/legacy fields only shows a single transfer.
Do you see multiple transfers, but just one of them being blocked?
Yes, there are some issues going back, you may have a destination url that is not correctly handled, because the older versions did not correctly handle a correctly encoded url.
For the UI, the editor is doing that work. For the CLI, the burden is on the user. You can use any URL encoding tool to encode the url. However, the parser does not require the full encoding that the UI does, it is just less error prone in the UI. For example, a url such as file:///C:\test is a valid URL and will parse correctly, but the UI will instead create something like file:///C%3A%5Ctest.
Yes. No encoding needs to be done when using the UI.
URL edit is supposed to parse the input and produce a strictly encoded output. Generally “flexible in input, strict in output”. The user is not expected to know about the URL format when using the UI. Users pasting in URLs should know how to encode the URL or at least check the results.
Yes and no.
Yes, both work and produce equivalent results.
No, because ngax still generates the relaxed URLs.
True. The relaxed format is really hard to document because it is “kind-of-url”. The new format is easy to document because it follows the RFC.