Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add x reason header to error responses #29

Merged
merged 3 commits into from
Nov 30, 2024

Conversation

0xtrr
Copy link
Owner

@0xtrr 0xtrr commented Nov 30, 2024

Refactors handlers to stop returning JSON body in error responses and instead set the X-Reason header as per BUD-01.
Adds a bunch of tests for the HEAD /upload endpoint to ensure that's also tested properly.

Fixes #19.

Replaces json error messages with the use of the X-Reason header as specified by BUD-01.
Updates error scenario tests to validate the header.
Adds a bunch of tests for the HEAD /upload endpoint.
Fixes a tiny bug in content length calculations.
@0xtrr
Copy link
Owner Author

0xtrr commented Nov 30, 2024

@laanwj would you mind taking a look at this PR? I usually just merge my own PRs but wouldn't hurt with some feedback if you have any. If you don't have time, I'll just merge it.

@laanwj
Copy link
Contributor

laanwj commented Nov 30, 2024

sure, will take a look

@laanwj
Copy link
Contributor

laanwj commented Nov 30, 2024

Code changes LGTM.

i don't know enough about implementations of blossom whether getting rid of JSON responses at the same time causes compatibility issues. But if so, they need to be updated to be compatible with BUD-01 anyway.

@0xtrr
Copy link
Owner Author

0xtrr commented Nov 30, 2024

Code changes LGTM.

i don't know enough about implementations of blossom whether getting rid of JSON responses at the same time causes compatibility issues. But if so, they need to be updated to be compatible with BUD-01 anyway.

BUD-01 just says that error responses MAY include the X-Reason header but nowhere does it mention returning a JSON response on error responses. Therefore I figured we'd just replace it entirely with the X-Reason header. The only difference is that you'd have to consume an error response from the header instead of the "message" field in the json response really.

@laanwj
Copy link
Contributor

laanwj commented Nov 30, 2024

The only difference is that you'd have to consume an error response from the header instead of the "message" field in the json response really.

Right. All it can affect is what error is displayed to the user, when something goes SNAFU anyway. It's fine imo.

@0xtrr 0xtrr merged commit c9ad39a into main Nov 30, 2024
1 check passed
@0xtrr 0xtrr deleted the add-x-reason-header-to-error-responses branch November 30, 2024 12:59
if let Ok(content_length) = content_length.parse::<u64>() {
let blob_size_in_mb = bytes_to_mb(content_length as f64);
if blob_size_in_mb > app_state.config.upload.max_size {
if let Ok(content_length) = content_length.parse::<f64>() {
Copy link
Contributor

@laanwj laanwj Nov 30, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oops i only notice this now. This isn't strictly correct. The Content-Length header should be parsed as an unsigned integer, not a floating point number. Better to keep it as <u64> then cast it to f64 later.

(This would accept things like Content-Length: -1e8 or Content-Length: 1.5 which make no sense)

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh right, I'll make a new PR for this

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add X-Reason header to error responses
2 participants