Resolved 11/14/2022
Hi @Maximilian_Haeussler – we have added in a change to restore the prior functionality. This is available at UseGalaxy.org so far, and the other usegalaxy.* servers will be updated soon.
Details HEAD and byte-range support · Issue #14982 · galaxyproject/galaxy · GitHub
Update 11/11/2022
We identified a change that appears to be on our side triggering the import issue. It was likely introduced in the last release. Details are in the public chat here You're invited to talk on Matrix
Happy to be wrong about this method “not ever” working 
We’ll post updates back here, and feel free to follow or join the chat. You can also message me directly to coordinate end-user communications around the anticipated fix when the time comes.
Thanks Max!
I saw that thread at the UCSC forum, too. Unless something changed very recently, hosting files from Galaxy to the UCSC browser should definitely still be possible.
As a guess, I think the problem with the particular file the user was asking about is that it didn’t have a “database” key assigned. It didn’t have one when I upload it here yesterday (seems Ok to post since is already public data, and I’ll unshare/purge in a day or two): Galaxy. A matching database -> dbkey is required for the UCSC link to even show up in Galaxy, so how that error was produced wasn’t clear.
Oh! I reread the post at UCSC. This part has clues:
The Url links to my workspace in Galaxy, where my bigWig files are saved. When I click Submit, the genome browser gives me the following warning:
Maybe the user isn’t linking directly from inside Galaxy, and instead trying to upload the file to the UCSC browser by URL? I forgot how that works on your end – do users target a specific dbkey/assembly for upload? That never worked from what I remember. People had to start in Galaxy and use the link inside a dataset that points to UCSC.
I will still take another look. More feedback, probably tomorrow.