Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use the last-modified response header as a pseudo-version if available #1821

Open
StSav012 opened this issue Sep 7, 2024 · 0 comments
Open
Labels
enhancement New feature or request

Comments

@StSav012
Copy link

StSav012 commented Sep 7, 2024

The change I propose is related to the pseudo-version generation, whenever a pseudo-version is used to tell whether an APK got an update.

The change does not lead to any breakage of existing user configs or operations. Neither does it require removing nor disabling any existing features of Obtanium.


To be clear, by the header I mean what I see when I run curl -I <URL> or a similar app.

If I get it right, the header is quite standard. And surely enough, if a server tells it once, it will send it every time. So, when a user adds an app to Obtanium, the latter can check what the server tells.

For instance, https://github.com/ImranR98/Obtainium/releases/download/v1.1.20/app-release.apk returns code 302 and a new location. There, no last-modified is present. If I follow the location, I'll get the response code 200 and last-modified: Tue, 20 Aug 2024 03:14:30 GMT. The release occurred on 2024-08-20T03:14:23Z. So, the value looks reliable.


I propose the following behavior.

First, conditions:

  1. A user has selected a pseudo-version to be used, or the source does not provide another option.
  2. An actual APK URL should be found and accessible by Obtanium.

Now, the actual roadmap.

  1. When a user is adding a new app, Obtanium follows the source until it gets a direct URL of an APK, one way or another. By “direct” I mean the response code to be 200, i.e., no redirection nor an error.
  2. Obtanium looks for the last-modified response header among the headers the server sends back.
    • If the header is present, its value is parsed and stored as the APK pseudo-version;
    • Otherwise, the current behavior (a partial download hash, etc.) is retained.
  3. As the headers are quick to get, the user sees the availability of the modification date almost instantly. If it's unavailable, the corresponding control is disabled.
  4. The server is expected to send the header either never or every time. So, if the header provided and is selected as the APK pseudo-version method, Obtanium should use it checking for the app updates.

Rationale 1.

Using human-readable dates might improve the UX. Furthermore, the last-modified response header might actually show how long ago an app was updated on a server.


Rationale 2.

Consider this URL: https://alfamobile-web.servicecdn.ru/latest/alfa-bank.apk.

The server responds 200, i.e., the APK is right there.

However, in Obtanium, it turns out that the pseudo-version takes one of three numeric values at random. The value changes whenever I overscroll the app page in Obtanium to refresh the data. This causes the APK to be re-installed over and over almost every time Obtanium checks for updates. It's not an issue in Obtanium.

To reproduce:
  1. In Obtanium, add https://alfamobile-web.servicecdn.ru/latest/alfa-bank.apk, override the source to read Direct APK Link.
  2. No need to actually install the app.
  3. Open the app details within Obtanium.
  4. See the Latest pseudo-version number.
  5. Pull down to refresh the info.
  6. See a different pseudo-version number. Possibly. Try the step 5 up to four times if the number stays the same.
How it looks:
screen.mp4
@StSav012 StSav012 added enhancement New feature or request to check Issue has not been reviewed labels Sep 7, 2024
@ImranR98 ImranR98 removed the to check Issue has not been reviewed label Sep 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants