Using URLs pointing to Dropbox hosted SRPMs no longer seems to work.

A Dropbox may look like this:
https://www.dropbox.com/s/34gsw45q5ge4fan/srelay-0.4.8p3-0.20181224.git688764b.fc10.3sunshine.src.rpm?dl=1

Wget and similar tools can fetch these files properly. copr used to have a problem with them (due to redirects, IIRC), but that was fixed years ago.

Now, recently, I am getting this error:

Traceback (most recent call last):
  File "/usr/bin/copr-rpmbuild", line 158, in main
    action(args, config)
  File "/usr/bin/copr-rpmbuild", line 244, in build_srpm
    produce_srpm(task, config, resultdir)
  File "/usr/bin/copr-rpmbuild", line 186, in produce_srpm
    provider.produce_srpm()
  File "/usr/lib/python3.6/site-packages/copr_rpmbuild/providers/spec.py", line 45, in produce_srpm
    raise RuntimeError("Url is not a path to .spec nor .src.rpm file")
RuntimeError: Url is not a path to .spec nor .src.rpm file

Presumably, the check in spec.py should clean the URI up first, in order for these URLs to work again.

https://pagure.io/copr/copr/blob/eb2507e5e4c7dc4c9d337c5b32b4f4612df25957/f/rpmbuild/copr_rpmbuild/providers/spec.py#_40

This code was added with commit e9e7592 some sixs months ago, but perhaps only recently pushed to https://copr.fedorainfracloud.org/coprs/ . Two months ago, this method still worked in my coprs.

(I may be wrong about the root cause, of course.)