Filesize limit

[yellowbluesky]

On inspection, while most downloaded images are under 1MB, a number of the imagesbeing downloaded are quite large; from 6 MBs up to 17MB.

Should be trivial if file size can be determined from Response body

[yellowbluesky]

As far as I can tell, the only way to determine file size without actually downloading the file itself with w GET is to use a HEAD request, and see if the filesize header is included.

In preliminary (but potentially flawed) testing with the above method, HEAD requests do not contain file size data.

I will test further, but it appears that this will not work.

[yellowbluesky]

Turns out I'm just dumb haha

I can call contentLength() on the Response, and that will return to me the size of the Response's body (image) in bytes.

Now I need to figure out how to integrate it into the current artwork filtering and getting flow:

• Currently the Response is obtained in getArtworkRanking() or getArtworkAuth() after filterRankingArtwork() or filterAuthArtwork() exits. Rejecting artwork must happen within the filtering methods in order to preserve the history of artworks already rejected and to be abale to properly signal for a new offset JSON.

• That can be easily worked around by getting filterRankingArtwork() or filterAuthArtwork() methods to grab the Response. For this I'll need a rework of method signatures and how exceptions are passed around

[yellowbluesky]

On further inspection

getArtworkRanking() needs the chosen artwork after filtering to grab variables to pass to Muzei (token, attribution).

I could package the relevant data in a struct / class (the response, and relevant artwork details), but I want to avoid doing it this way if possible

[yellowbluesky]

I can have the loop that normally runs in filterArtworkRanking() be run in getArtworkRanking()