Parallel request failures don't include url in error message

[Earnestly]

• Linux 5.9.0

When making use of the new parallel feature it it appears that any request failures don't include the url from which the error came from. For example I have seen the following:

curl: (92) HTTP/2 stream 0 was not closed cleanly: INTERNAL_ERROR (err 2)
curl: (92) HTTP/2 stream 0 was not closed cleanly: INTERNAL_ERROR (err 2)
curl: (22) The requested URL returned error: 502 
curl: (22) The requested URL returned error: 502 
curl: (22) The requested URL returned error: 502 
curl: (22) The requested URL returned error: 502 
curl: (22) The requested URL returned error: 502 
curl: (22) The requested URL returned error: 502 
curl: (22) The requested URL returned error: 502 
curl: (22) The requested URL returned error: 502 
curl: (22) The requested URL returned error: 502 

Due to the lack of a url in the message itself, it's hard to know where these errors are from to take any corrective action.

curl version

curl 7.74.0-DEV (x86_64-pc-linux-gnu) libcurl/7.74.0-DEV OpenSSL/1.1.1h zlib/1.2.11 zstd/1.4.5 libidn2/2.3.0 libpsl/0.21.1 (+libidn2/2.3.0) nghttp2/1.41.0 librtmp/2.3
Release-Date: [unreleased]
Protocols: dict file ftp ftps gopher http https imap imaps mqtt pop3 pop3s rtmp rtsp smb smbs smtp smtps telnet tftp 
Features: alt-svc AsynchDNS GSS-API HTTP2 HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM NTLM_WB PSL SPNEGO SSL TLS-SRP UnixSockets zstd

[bagder]

... and even with a URL shown it could be hard to tell if you for example use the same URL multiple times and only one or some of them fail! Maybe it should then also refer to which number of the URL it was?

[Earnestly]

I hadn't thought of that scenario as my use cases have always used unique urls. Perhaps the idea of indexing them can work as curl already has the notion of position dependent urls and options on the command-line.