https://bugs.kde.org/show_bug.cgi?id=501276
Bug ID: 501276
Summary: Support HTTP URIs as arguments to the
`--local-filename` parameter.
Classification: Applications
Product: Discover
Version: 6.3.2
Platform: Fedora RPMs
URL: https://discuss.kde.org/t/discovers-local-filename-fla
g-should-support-external-uris-too/12857?u=rokejulianl
ockhart
OS: Linux
Status: REPORTED
Severity: wishlist
Priority: NOR
Component: PackageKit
Assignee: plasma-b...@kde.org
Reporter: 4wy78...@rokejulianlockhart.addy.io
CC: aleix...@kde.org
Target Milestone: ---
SUMMARY
-------
Providing an HTTP[S] URI serving a `.flatpak` file to the `--local-filename`
flag of `plasma-discover-6.3.2-1.fc41.x86_64` results in an error, despite it
functioning with a `file:///` URI pointing to the same file (when stored
locally). Considering that `flatpak-1.16.0-1.fc41.x86_64`, OSTW's `zypper`, and
FC41's `dnf5-5.2.10.0-2.fc41.x86_64` all support HTTP URIs as arguments to
their installation parameters, Discover should support this.
STEPS TO REPRODUCE
------------------
1. Install `plasma-discover-6.3.2-1.fc41.x86_64`.
2. Provide an HTTP[S] URI serving a `.flatpak` file to its `--local-filename`.
OBSERVED RESULT
---------------
If accessed via `firefox-136.0-2.fc41.x86_64`, I see a valid response:
> ~~~HTTP
> HTTP/2 200
> content-type: application/octet-stream
> last-modified: Mon, 11 Mar 2024 04:36:49 GMT
> etag: "0x8DC4184DE4008CC"
> server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0
> x-ms-request-id: 5af19293-b01e-003f-0239-9129f6000000
> x-ms-version: 2025-01-05
> x-ms-creation-time: Mon, 11 Mar 2024 04:36:49 GMT
> x-ms-blob-content-md5: zmnaghRa6M/tXsmxRbDXBg==
> x-ms-lease-status: unlocked
> x-ms-lease-state: available
> x-ms-blob-type: BlockBlob
> content-disposition: attachment; filename=naps2-7.4.0-linux-x64.flatpak
> x-ms-server-encrypted: true
> via: 1.1 varnish, 1.1 varnish
> fastly-restarts: 1
> accept-ranges: bytes
> date: Sun, 09 Mar 2025 21:31:56 GMT
> age: 328
> x-served-by: cache-iad-kcgs7200031-IAD, cache-lon420123-LON
> x-cache: MISS, HIT
> x-cache-hits: 0, 1
> x-timer: S1741555917.611357,VS0,VE1
> content-length: 20338640
> X-Firefox-Spdy: h2
> ~~~
However, if provided as an argument to the `--local-filename` flag, it errors:
> ~~~QML
> org.kde.plasma.libdiscover: OdrsReviewsBackend: Fetch ratings: false
> adding empty sources model QStandardItemModel(0x56493d02af10)
> qrc:/qt/qml/org/kde/discover/qml/LoadingPage.qml:3:1: QML LoadingPage:
> Created graphical object was not placed in the graphics scene.
> qrc:/qt/qml/org/kde/discover/qml/BrowsingPage.qml:17:1: QML BrowsingPage:
> Created graphical object was not placed in the graphics scene.
> KNSCore::ResultsStream(0x56493eeb82e0) Finishing
> KNSCore::StaticXmlProvider(0x7f735c014ad0) 0
> ~~~
EXPECTED RESULT
---------------
It should the same as it would if the file had been supplied via a `file://`
URI.
SOFTWARE/OS VERSIONS
--------------------
1. ~~~sh
#!/usr/bin/env sh
kinfo
~~~
1. > ~~~YAML
> Operating System: Fedora Linux 41
> KDE Plasma Version: 6.3.2
> KDE Frameworks Version: 6.11.0
> Qt Version: 6.8.2
> Kernel Version: 6.13.5-200.fc41.x86_64 (64-bit)
> Graphics Platform: Wayland
> Processors: 12 × AMD Ryzen 5 7600X 6-Core Processor
> Memory: 30.4 GiB of RAM
> Graphics Processor 1: AMD Radeon RX 5700
> Graphics Processor 2: AMD Radeon Graphics
> ~~~
ADDITIONAL INFORMATION
----------------------
I expect that this isn't a matter of locality versus externality, since
`file://` URIs support hostnames other than `localhost` (the default for
`file:///`). Rather, it merely isn't yet designed to support alternative
schemas. Considering that Dolphin utilises KIO to support myriad methods of
acquiring content via HTTP[S], FTP[S], and WebDav, et cetera, Dolphin should be
able to without reinventing much.
I've reported this to the PK backend, because I believe that this affects RPM
files, too.
--
You are receiving this mail because:
You are watching all bug changes.
