James Hodgkinson

See #1906 - closing this.

So we aren't vulnerable to big request sizes.... but we can't accept them now either. This [issue in the hyper repo](https://github.com/hyperium/hyper/issues/2384) explains why - once you hit a predetermined body...

I'm going to have a play around with them at some point, but something is short-circuiting the response when it sends the 100 header, hence the intermittent failure (the second...

from [the docs on request body limits](https://docs.rs/axum/0.6.20/axum/extract/index.html#request-body-limits) > For security reasons, [Bytes](https://docs.rs/bytes/1.4.0/x86_64-unknown-linux-gnu/bytes/bytes/struct.Bytes.html) will, by default, not accept bodies larger than 2MB. This also applies to extractors that uses [Bytes](https://docs.rs/bytes/1.4.0/x86_64-unknown-linux-gnu/bytes/bytes/struct.Bytes.html) internally...

ima leave it open and fix the "body isn't consumed properly" thing because it causes threads to panic

> A slightly different _http_ endpoint may be nice for Kubernetes probes (https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/). I don't think it would work with https, especially with a self-signed or private root CA signed...

No worries, easy to do, I originally went looking for the options to set to skip it 😄

I have plans to investigate Otel metrics/traces, but they're not in place yet. In fact the Otel method is *less* vendor-specific due to its open nature 😄

Another thread to note is https://github.com/kanidm/kanidm/discussions/1455

The issue is really doing the fingerprinting and identification on the server side, more than the storage requirements or enabling users to manipulate a security feature