- Using httpProxy or httpsProxy hostname with uppercases , then validation fails and the setup from ingress operator will fail ( ConfigMap: trusted-ca) and the operator pods will not start Error: "message": "The configuration is invalid for proxy ‘cluster’ (invalid httpProxy URI: failed validating URI \“http://MYPROXY.EXAMPLE.COM:8080\“: invalid host: MYPROXY.EXAMPLE.COM). Use ’oc edit proxy.config.openshift.io' Code where the error is: https://github.com/openshift/cluster-network-operator/blob/4b9efdc9add4ba27bdd30c20d7d22095ef8f3e1f/vendor/k8s.io/apimachinery/pkg/util/validation/validation.go#L116 Please let me know if you need more info.
As per RFC3986 this should be allowed: https://tools.ietf.org/html/rfc3986#section-3.2.2 ~~~ The host subcomponent of authority is identified by an IP literal encapsulated within square brackets, an IPv4 address in dotted- decimal form, or a registered name. The host subcomponent is case- insensitive. ~~~ I see we use a dns 1123 matcher As per RFChttps://tools.ietf.org/html/rfc1123#page-13 ~~~ 2.1 Host Names and Numbers The syntax of a legal Internet host name was specified in RFC-952 [DNS:4]. One aspect of host name syntax is hereby changed: the restriction on the first character is relaxed to allow either a letter or a digit. Host software MUST support this more liberal syntax. Host software MUST handle host names of up to 63 characters and SHOULD handle host names of up to 255 characters. Whenever a user inputs the identity of an Internet host, it SHOULD be possible to enter either (1) a host domain name or (2) an IP address in dotted-decimal ("#.#.#.#") form. The host SHOULD check the string syntactically for a dotted-decimal number before looking it up in the Domain Name System. ~~~ And RFC 952 says: https://tools.ietf.org/html/rfc952 ~~~ 1. A "name" (Net, Host, Gateway, or Domain name) is a text string up to 24 characters drawn from the alphabet (A-Z), digits (0-9), minus sign (-), and period (.). Note that periods are only allowed when they serve to delimit components of "domain style names". (See RFC-921, "Domain Name System Implementation Schedule", for background). No blank or space characters are permitted as part of a name. No distinction is made between upper and lower case. ~~~ Now checking why this line is here, turns out what kubernetes calss DNS-1123 isn't actually RFC 1123: https://github.com/kubernetes/kubernetes/pull/39675 I believe this is a valid bug.
Hi Gabriel, Could you let me know the steps how to reproduce the issue? I tried to reproduce the issue in old version by below way. But I cannot reproduce it. With "oc edit proxy.config.openshift.io", using httpProxy or httpsProxy hostname with uppercases, no error messages. huiran-mac:script hrwang$ oc edit proxy.config.openshift.io proxy.config.openshift.io/cluster edited huiran-mac:script hrwang$ oc get proxy.config.openshift.io -o yaml apiVersion: v1 items: - apiVersion: config.openshift.io/v1 kind: Proxy metadata: creationTimestamp: "2020-02-17T01:37:21Z" generation: 3 name: cluster resourceVersion: "719453" selfLink: /apis/config.openshift.io/v1/proxies/cluster uid: c000f406-f1b3-482b-b8a9-79c8200466ec spec: httpProxy: http://MYPROXY.EXAMPLE.COM:8080 httpsProxy: http://MYPROXY.EXAMPLE.COM:8080 trustedCA: name: "" status: {} kind: List metadata: resourceVersion: "" selfLink: ""
Verified in 4.4.0-0.nightly-2020-02-18-200822
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2020:0581