Change UA to distinguish rpi-imager traffic

[waveform80]

At the moment, the rpi-imager uses a rather generic user-agent when requesting images (and JSON meta-data) from its servers. Specifically, it's just "Mozilla/5.0" (presumably a default in Qt somewhere). The team here at Canonical were wondering if it would be possible to change the user-agent to something a bit more unique to more easily distinguish requests from the imager (maybe something like "Mozilla/5.0 rpi-imager/1.2", just in case anything's relying on the current "Mozilla/5.0" prefix for compatibility) from other traffic.

I should stress this wouldn't be used to serve anything different, i.e. unlike the case mentioned in #17 where a user-agent change was mooted to get around Sourceforge serving different things to what it thought was "browser" or "not-browser" based on UA. This would purely be so we could determine a bit more easily what proportion of image downloads were definitely from the imager (vs anonymized or default UAs).

I'm happy to put together a PR for this, if it's acceptable?

[maxnet]

Do be aware that changing the user-agent everywhere is a little less trivial than it may appear.

The image downloads themselves are handled by libcurl and that does allow customization of the user-agent.
The JSON meta-data however is downloaded in QML Javascript code using XMLHttpRequest.
I would not count that you can change the user-agent with that easily without having to change the Qt library code (which we do not control on platforms like Linux, in which the libraries are provided by the distro).

[waveform80]

That would still be useful insofar as the image downloads are the primary concern here (i.e. I'd still be happy to whip up something that customized the curl UA alone, if that's acceptable).

That said, if QML implements XMLHttpRequest, wouldn't it be possible to use setRequestHeader to customize the UA on the JSON requests too? The UA is "just" a request header after all?

[maxnet]

That said, if QML implements XMLHttpRequest, wouldn't it be possible to use setRequestHeader to
customize the UA on the JSON requests too?

Think that disallows changing certain headers including user-agent.
See: https://github.com/qt/qtdeclarative/blob/73894987a22c9821c508c921f38a0db442559c71/src/qml/qml/qqmlxmlhttprequest.cpp#L1826

But haven't tested it.

[ghollingworth]

I agree, it's probably more useful to track image downloads than it is json file downloads.

Of course you'll never be able to track multiple installations of a cached image, but that's fine, it would just be good to understand what the comparison is between people installing with Imager and those installing using raw images...

Gordon

[lurch]

I guess JSON file downloads (metadata used to build the image-selector menu) potentially covers every time RPi Imager ever gets launched? 😉 And those files are probably only ever downloaded by RPi Imager anyway?

[waveform80]

That said, if QML implements XMLHttpRequest, wouldn't it be possible to use setRequestHeader to
customize the UA on the JSON requests too?

Think that disallows changing certain headers including user-agent.
See: https://github.com/qt/qtdeclarative/blob/73894987a22c9821c508c921f38a0db442559c71/src/qml/qml/qqmlxmlhttprequest.cpp#L1826

But haven't tested it.

Doh, that certainly would seem to put paid to my setRequestHeader idea (side note: slightly annoying given they're obviously trying to follow the spec there, in which certain headers are forbidden for good security reasons, but UA isn't one of them). Oh well, c'est la vie.

[waveform80]

I guess JSON file downloads (metadata used to build the image-selector menu) potentially covers every time RPi Imager ever gets launched? wink And those files are probably only ever downloaded by RPi Imager anyway?

Other than the odd wget from odd-balls like me trying to figure out what rpi-imager is looking at, very likely :)

[ghollingworth]

Although that's not the intention, there's no reason why someone else couldn't parse our .json file to develop their own installation system for example, or even just a simple script to go get the link to the latest raspbian image...

[ghollingworth]

OK, closing this issue and moving discussion to the pull request