A couple of points here:
1) I agree that its not an issue with our code here. Its a problem that
exists in other third party intermediary servers which are not compliant.
2) I agree that the POST hack instead of GET could be seen as being
against the REST principals, but its still REST compliant (POST is still
unsafe and idempotent. It could be seen still as creating a new resource
which is returned but not stored on the server). It might not be the
most performant thing to use since caching servers are out of the
question. Its what is currently used in InfluxDB as a way to get around
this issue.
This is not just an issue with the Kubernetes proxy, its also an issue
with EAP, other web server, other apache components (or at least some
older versions), and apparently a bunch of other proxies servers out
there. Its a common enough problem in this space that we have already
ran into in two places when dealing with OpenShift integration work.
I don't think its acceptable to say that since we are compliant, its not
our fault and we wont to anything to help get anyone get around this
issue. We need to work in the real world and this means having to
(potentially) deal with the common problems which exist out there.
For now, it looks like we are just going to disable certain checks in
EAP to bypass the error there and try and patch the kubernetes proxy to
get around the issue.
Hopefully this will be enough for now and that we don't run into other
issues in the near future. But we may want to consider making things
easier when we know this is a potential problem area.
- Matt
On 21/09/15 08:14 AM, Thomas Segismont wrote:
Le 21/09/2015 13:15, Michael Burman a écrit :
> I don't think this is a valid reason (as the proxy can be fixed by avoiding
Golang's url.Parse() command) to change our implementation and APIs.
+1
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev