]> git.proxmox.com Git - proxmox-backup.git/commit
server: rest: implement max URI path and query length request limits
authorThomas Lamprecht <t.lamprecht@proxmox.com>
Thu, 15 Oct 2020 15:49:16 +0000 (17:49 +0200)
committerDietmar Maurer <dietmar@proxmox.com>
Fri, 16 Oct 2020 08:40:39 +0000 (10:40 +0200)
commit4703ba81ce0b270f6c84bc2fd52784140ccdf71e
treef02796c54d097b0b3b587bea231d415f3bcc10c6
parent29633e2fe9684b5a34ccb9bbcea596451848a01c
server: rest: implement max URI path and query length request limits

Add a generous limit now and return the correct error (414 URI Too
Long). Otherwise we could to pretty larger GET requests, 64 KiB and
possible bigger (at 64 KiB my simple curl test failed due to
shell/curl limitations).

For now allow a 3072 characters as combined length of URI path and
query.

This is conform with the HTTP/1.1 RFCs (e.g., RFC 7231, 6.5.12 and
RFC 2616, 3.2.1) which do not specify any limits, upper or lower, but
require that all server accessible resources mus be reachable without
getting 414, which is normally fulfilled as we have various length
limits for stuff which could be in an URI, in place, e.g.:
 * user id: max. 64 chars
 * datastore: max. 32 chars

The only known problematic API endpoint is the catalog one, used in
the GUI's pxar file browser:
GET /api2/json/admin/datastore/<id>/catalog?..&filepath=<path>

The <path> is the encoded archive path, and can be arbitrary long.

But, this is a flawed design, as even without this new limit one can
easily generate archives which cannot be browsed anymore, as hyper
only accepts requests with max. 64 KiB in the URI.
So rather, we should move that to a GET-as-POST call, which has no
such limitations (and would not need to base32 encode the path).

Note: This change was inspired by adding a request access log, which
profits from such limits as we can then rely on certain atomicity
guarantees when writing requests to the log.

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
src/server/rest.rs