- Rust 94.5%
- Clojure 1.8%
- Shell 1.7%
- Nix 1.2%
- Python 0.6%
- Other 0.2%
| Filename | Latest commit message | Latest commit date |
|---|---|---|
3ebe456197
Path-style URLs of the form /bucket//key address an object whose key begins with "/". Two greedy uses of `trim_start_matches('/')` were collapsing these leading slashes away:
- `uri.path().trim_start_matches('/')` stripped all leading slashes from the raw path before any further parsing.
- `p.trim_start_matches('/')` stripped leading slashes from the remainder after `split_once('/')` had already consumed the bucket/key separator
The combined effect wath that `HEAD /bucket//` and `GET /bucket//` produced an empty key, which the router treated as bucket-level operations (HeadBucket -> 200 OK, and ListObjectsV2) instead of an object-level op (HeadObject/GetObject -> 404 NoSuchKey).
The fix is simple: Replace the first `trim_start_matches` with `strip_prefix` (to strip exactly one separator slash) and remove the second one entirely. Path-style and vhost-style requests are now consistent: a double slash in the URL correctly addresses a key whose name begins with "/".
Regression tests added for `HEAD //` and `GET //` requests in both request styles.
Fixes: #1464
---
Disclaimer: I'm not fluent in Rust and I did use an LLM to explain the code to me. All code was written by me.
I'm not sure whether the large `test_cases!` block in the `test_aws_doc_examples` function is the right place for my tests (it certainly was a convenient one).
Reviewed-on: https://git.deuxfleurs.fr/Deuxfleurs/garage/pulls/1465
|
||
| .woodpecker | ||
| doc | ||
| fuzz | ||
| nix | ||
| script | ||
| src | ||
| .dockerignore | ||
| .envrc | ||
| .gitignore | ||
| Cargo.lock | ||
| Cargo.toml | ||
| CONTRIBUTING.md | ||
| default.nix | ||
| Dockerfile | ||
| flake.lock | ||
| flake.nix | ||
| LICENSE | ||
| Makefile | ||
| README.md | ||
| rustfmt.toml | ||
| SECURITY.md | ||
| shell.nix | ||
| taplo.toml | ||
| typos.toml | ||
Garage 
[ Website and documentation | Binary releases | Git repository | Matrix channel ]
Garage is an S3-compatible distributed object storage service designed for self-hosting at a small-to-medium scale.
Garage is designed for storage clusters composed of nodes running at different physical locations, in order to easily provide a storage service that replicates data at these different locations and stays available even when some servers are unreachable. Garage also focuses on being lightweight, easy to operate, and highly resilient to machine failures.
Garage is built by Deuxfleurs, an experimental small-scale self hosted service provider, which has been using it in production since its first release in 2020.
Learn more on our dedicated documentation pages:
Garage is entirely free software released under the terms of the AGPLv3.