Description

Related to https://github.com/imgix/js-core#variable-qualities

Add a variable_qualities option to the https://github.com/imgix/imgix-java#fixed-width-images function to allow users to override the mapping of the quality parameter (q) to each device pixel ratio (dpr). This will allow users to have more granular control over the fixed-size srcset values generated.

I followed the README and realized the version number written now is not mirrored to jcenter.

compile "com.imgix:imgix-java:1.1.11"

I checked the jcenter website and found ver 1.1.10, and only that version is mirrored to jcenter.
https://bintray.com/imgix/maven/imgix-java

thanks.

This use case arises when we pass in the path URI which contains /, createURL converts them to %2F which breaks the URL. Example, builder.createURL("photos/x1/abc.jpg", params). This spits out the URL as http://domain/photos%2Fx1%2Fabc.jpg?{params}

URLHelper is calling platform dependent String.getBytes() here:

private String encodeBase64(String str) {
	byte[] stringBytes = str.getBytes();

But as far as I know base64 encoding for urls require UTF-8 to be used and should be specified explicitly here.

Running this example program:

public class ImgixExample {
    public static void main(String[] args) {
        System.out.println("Default charset: " + Charset.defaultCharset());
        URLBuilder builder = new URLBuilder("demos.imgix.net");
        Map<String, String> params = new HashMap<String, String>();
        params.put("m64", "http://demos.imgix.net/bridge.png?ixlib=java-2.1.0");
        System.out.println(builder.createURL("bridge.png", params));
    }
}

with -Dfile.encoding=UTF-8 and -Dfile.encoding=UTF-32 respectively demonstrates the problem:

Default charset: UTF-8
http://demos.imgix.net/bridge.png?ixlib=java-2.1.0&m64=aHR0cDovL2RlbW9zLmltZ2l4Lm5ldC9icmlkZ2UucG5nP2l4bGliPWphdmEtMi4xLjA

Default charset: UTF-32
http://demos.imgix.net/bridge.png?ixlib=java-2.1.0&m64=�������������������������������������������������������������������

Unlike the javascript API, the java API forces you to double url-encode the source URL path provided to createURL.

Steps to reproduce:

• Have a file located at https://my.domain/project:1/blah.jpg
• URL-encode it once, so that it becomes https://my.domain/project%3A1/blah.jpg
• Use HTTPBuilder.createURL to create an imgix URL against your imgix domain.
• Attempt to curl that URL, see that it fails.
• generate another URL by doubly-encoding: builder.createURL(java.net.URLEncoder.encode("https://my.domain/project%30A1/blah.jpg", "UTF-8"), params)
• Attempt to curl that URL, see that it succeeds.

Expected behavior:

• I expect that I can pass a valid, singly encoded URL into createURL and get a valid imgix URL out.

Hi! first of all, thanks for this great library.

I'm trying to implement ImgIx on android app and I'm getting the following warning:

Invalid package reference in library; not included in Android: javax.xml.bind. Referenced from com.imgix.URLHelper.

I tried adding this rule to proguard without success

-dontwarn javax.xml.**

Description

Related to https://github.com/imgix/js-core#fixed-image-rendering

Add a devicePixelRatios option to the https://github.com/imgix/imgix-java#fixed-width-images function to allow users to customize the target device pixel ratio(s) (dpr) when generating a fixed image. This will allow users to have more granular control over the fixed-size srcset values generated.

Please also publish sources JAR and javadoc JAR, not just binary JAR.

In Maven you simply do source:jar javadoc:jar before deploy. Should have same feature in Gradle.

Thank you.

Hello,

There is a published CVE in the Java SDK affecting the latest version too. The CVE is https://nvd.nist.gov/vuln/search/results?form_type=Advanced&results_type=overview&search_type=all&cpe_vendor=cpe%3A%2F%3Aimgix&cpe_product=cpe%3A%2F%3Aimgix%3Aimgix&cpe_version=cpe%3A%2F%3Aimgix%3Aimgix%3A2.3.0

Also attched is the screengrab from my development machine detailing the CVE.

Are there any plans to fix this in a future update ?

Thank you for your attention.

JFrog is shutting down JCenter. Is there a plan to move this library to Maven Central?

Announcement here: https://jfrog.com/blog/into-the-sunset-bintray-jcenter-gocenter-and-chartcenter/

Relevant dates:

• 2021-03-31 - No new package versions after this date
• 2021-05-01 - REST API & UI shutdown
• 2022-02-01 - JCenter repo (downloads) shutdown