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

Try HTTP right away if secure HTTPS fails with HttpHostConnectException if allowInsecureRegistries #767

Closed
chanseokoh opened this issue Aug 1, 2018 · 2 comments
Assignees
Milestone

Comments

@chanseokoh
Copy link
Member

chanseokoh commented Aug 1, 2018

Suppose the registry part of an image reference doesn't have a port specified and the registry is HTTP (at port 80).

0.9.7 firsts tries port 443, and it will fail with HttpHostConnectException because the port 443 is not listening. 0.9.7 catches the exception and fall backs to HTTP (trying port 80).

In #733, I did not fully understand when exactly HttpHostConnectException can happen, so I caught the exception only when attempting an insecure HTTPS, falsely thinking that this would preserve the 0.9.7 behavior.

However, in this scenario, we should catch HttpHostConnectException at the first attempt of secure HTTPS, and fall back right into HTTP, bypassing insecure HTTPS.

Note that 0.9.8 still works in this scenario if the image reference contains the port (e.g., localhost:80/repository/image. Hopefully people usually don't run an HTTP registry on port 80.

@chanseokoh chanseokoh self-assigned this Aug 1, 2018
@coollog coollog added this to the v0.9.9 milestone Aug 1, 2018
@chanseokoh
Copy link
Member Author

chanseokoh commented Aug 1, 2018

Actually the 0.9.7 behavior was not ideal either. When getting HttpHostConnectException, I think we should fall back to HTTP only in the following situation:

  1. allowInsecureRegistries is true, of course.
  2. No port was explicitly given, so we tried the default HTTPS port 443.
  3. We couldn't connect to the port 443.

Then it makes sense to try HTTP at port 80, which is a different port. Otherwise, we surface the HttpHostConnectException instead of blindly falling back to HTTP. That might have contributed problems like #746 (comment) and #746 (comment).

@chanseokoh
Copy link
Member Author

chanseokoh commented Aug 2, 2018

Actually the 0.9.7 behavior was not ideal either.

That might have contributed problems like #746 (comment) and #746 (comment) (although this is just a totally wild guess.)

Indeed, with 0.9.7, if you just can't connect to the registry because, e.g., the registry is temporarily down, Jib prints out a misleading error. For example, if I specify a registry endpoint that doesn't work on purpose,

          <from>
            <image>google.com:1234/chanseok/image-built-with-jib</image>
          </from>

then I get the following error:

[ERROR] Failed to execute goal com.google.cloud.tools:jib-maven-plugin:0.9.7:build (default-cli) on project helloworld: Build image failed, perhaps you should use a registry that supports HTTPS or set the configuration parameter 'allowInsecureRegistries': Only secure connections are allowed, but tried to reach URL http://google.com:1234/v2/chanseok/image-built-with-jib/manifests/latest -> [Help 1]

This is because 0.9.7 blindly attempts HTTP, which will immediately fail with the misleading error because allowInsecureRegistries is not set.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants