We've dropped the content-type field since it is effectively unbounded
(we had a sec-vuln about this before actually). We retain all other
fields, despite their unboundedness due to the fact that we can now
explicitly set bounds on label values.
Change-Id: Icc483fc6a17ea6382928f4448643cda6f3e21adb
Kubernetes-commit: cfd00de6866e636332bdcd3f46d6d2ffd8d2bc88
* fix a number of unbounded dimensions in request metrics
* add test suite for cleanVerb and cleanContentType
* Properly validate that the content-type and charset (if applicable) are RFC compliant
* add additional test case
* truncate list of content-types
Change-Id: Ia5fe0d2e2c602e4def4b8e0849cc19f3f9251818
Kubernetes-commit: 6c588c3f441252f42fd37526297ed92d1e1f3acf
When adding InstallPathHandler it was suggested to follow-up with an improvement to the unit tests.
Kubernetes-commit: 1a0eb8c7b6fc0e07e8823d635db9b70f128dee4f
Currently it is only possible to have one group of checks which must all pass for the handler to report success.
Allowing multiple paths for these checks allows use of the same machinery for other kinds of checks, i.e. readiness.
Kubernetes-commit: 2082a0f42851c47620ce31f257dcb5536abae014
- InstallHandler is the public interface through which all interaction
occurs.
- It is good to know whether the default ping is occurring to know due
to manual installation or automatic installation.
- It is good to know how many handlers are installed to see whether
code changes are taking effect.
- It is good to know the names of the handlers that are installed to
make sure that a handler a user thinks is installed is being
installed at runtime.
- Print all the checkers once
Kubernetes-commit: efa66227d4fbcfad9fec21755b898f5d10d3344c