bug: query parameters and fragments in download URLs corrupt filenames, crash on Windows, and break format detection

[yush-1018]

Bug Report

Describe the bug
In databusclient/api/download.py (line 452), target filenames are derived by naive slash-splitting of the raw download URL:

file = url.split("/")[-1]
filename = os.path.join(localDir, file)

When downloading files from URLs that contain query parameters or fragments (such as presigned S3/GCS links, Nextcloud/WebDAV shared links, or token-based downloads like https://example.org/data.ttl.bz2?token=abc123&expires=1700000), the entire query string remains attached to file (data.ttl.bz2?token=abc123&expires=1700000).

This causes two critical issues:

1. Windows crash: On Windows, ? is a reserved illegal character in file paths. Opening the file with open(filename, "wb") crashes immediately with OSError: [Errno 22] Invalid argument.
2. Format & compression detection failure: On Linux/macOS, the file is saved with the query string in its name. Subsequent checks like _detect_compression_format(file) (which checks .endswith(".bz2") or .endswith(".gz")) fail because the filename ends with the query parameters instead of the file extension. Consequently, on-the-fly decompression (--compression none) and format conversions fail.

To Reproduce
Attempt to download any file using a URL that contains query parameters:

databusclient download "https://raw.githubusercontent.com/dbpedia/databus-python-client/main/tests/resources/test.ttl?raw=true"

• On Windows: immediate crash with OSError: [Errno 22] Invalid argument.
• On Linux/macOS: saved as test.ttl?raw=true and format detection fails.

Expected behavior
The client should parse the URL and extract the clean path component without query strings or fragments, ensuring safe file paths across all operating systems and proper format detection.

Proposed Solution
Extract the clean basename from the URL's path component using standard library tools:

import posixpath
from urllib.parse import unquote, urlparse

url_path = urlparse(url).path
file = posixpath.basename(unquote(url_path)) or "downloaded_file"
filename = os.path.join(localDir, file)

[Integer-Ctrl]

Overall, the databus-python-client is a tool for the databus and not intended for downloading arbitrary files. So I don't think that this is a problem which has to be fixed.

Is this problem reproducible with any data on https://databus.dev.dbpedia.link/ or https://databus.dbpedia.org/?

[yush-1018]

@Integer-Ctrl,

I was mostly thinking about cases where a dataset's downloadURL points to external storage like Zenodo (which uses ?download=1) or Nextcloud links, where Windows crashes because ? isn't allowed in file paths.

If all official Databus datasets strictly use clean URLs without query params, I'm completely fine with closing this PR if it's not needed. What do you think?

[Integer-Ctrl]

My question was, if this is reproducible 😄 I guess it's not, but correct me

[Integer-Ctrl]

Published https://zenodo.org/records/21290442/files/data_dictionary.csv?download=1 and tested myself. I see no problem, do you?

databusclient download https://databus.dbpedia.org/databus-python-client/test-data/download-url/2026-09-18

[yush-1018]

Tested it on Windows with your test dataset, and you're totally right!

Since the client resolves the local filename from the Databus URI (download-url.csv) before following the redirect, the query parameters on the Zenodo URL don't affect the local filename at all.

Thanks a lot for publishing the test dataset on Databus to verify this!