it's a 'http' utility crate
* the extra 'http' module is redundant
* the module name 'helpers' as a public path doesn't say
much about what it does
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
this is just a (rather HTTP specific) wrapper, so put it into a
'wrapper' module for now.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
with test1/3 we only tested the regex, which is now gone
transform the tests to valid emails, so we test this also
and rename them to know what they should test
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
by removing the regex check here, that is responsibility of the caller
this is ok since we pass the args directly and not via shell, so
command injection should not be possible
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
- refactor the combinators,
- make it take a `&T: Serialize` instead of a Value, and
allow sending the raw string via `send_raw_command`.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
The :vis macro matcher has been stable for a long time now.
Let's use it, and replace the recursion with a plus pattern.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
basically the same as commit 5fb15b781e
Will be required once we get to use a newer rustc, at least the
client build for archlinux was broken due to this.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Adds convenience helpers `.owner_root()`.
Unfortunately for the group equivalent `nix` needs to have
const `Gid` constructors...
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
style wise, bounds should refer to AsyncRead instead
also we don't actually use any of the Ext methods
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
This allows switching the base user identification/authentication method
in the rest server. Will initially be used for single file restore VMs,
where authentication is based on a ticket file, not the PBS user
backend (PAM/local).
To avoid putting generic types into the RestServer type for this, we
merge the two calls "extract_auth_data" and "check_auth" into a single
one, which can use whatever type it wants internally.
Signed-off-by: Stefan Reiter <s.reiter@proxmox.com>
I made some comparision with bombardier[0], the one listed here are
30s looped requests with two concurrent clients:
[ static download of ext-all.js ]:
lvl avg / stdev / max
none 1.98 MiB 100 % 5.17ms / 1.30ms / 32.38ms
fastest 813.14 KiB 42 % 20.53ms / 2.85ms / 58.71ms
default 626.35 KiB 30 % 39.70ms / 3.98ms / 85.47ms
[ deterministic (pre-defined data), but real API call ]:
lvl avg / stdev / max
none 129.09 KiB 100 % 2.70ms / 471.58us / 26.93ms
fastest 42.12 KiB 33 % 3.47ms / 606.46us / 32.42ms
default 34.82 KiB 27 % 4.28ms / 737.99us / 33.75ms
The reduction is quite better with default, but it's also slower, but
only when testing over unconstrained network. For real world
scenarios where compression actually matters, e.g., when using a
spotty train connection, we will be faster again with better
compression.
A GPRS limited connection (Firefox developer console) requires the
following load (until the DOMContentLoaded event triggered) times:
lvl t x faster
none 9m 18.6s x 1.0
fastest 3m 20.0s x 2.8
default 2m 30.0s x 3.7
So for worst case using sligthly more CPU time on the server has a
tremendous effect on the client load time.
Using a more realistical example and limiting for "Good 2G" gives:
none 1m 1.8s x 1.0
fastest 22.6s x 2.7
default 16.6s x 3.7
16s is somewhat OK, >1m just isn't...
So, use default level to ensure we get bearable load times on
clients, and if we want to improve transmission size AND speed then
we could always use a in-memory cache, only a few MiB would be
required for the compressable static files we server.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
implements a deflate encoder that can compress anything that implements
AsyncRead + Unpin into a file with the helper 'compress'
if the inner type is a Stream, it implements Stream itself, this way
some streaming data can be streamed compressed
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
