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

React to a 413 (Content too large) response #2732

Open
peb-adr opened this issue Aug 31, 2023 · 3 comments
Open

React to a 413 (Content too large) response #2732

peb-adr opened this issue Aug 31, 2023 · 3 comments
Labels
Milestone

Comments

@peb-adr
Copy link
Member

peb-adr commented Aug 31, 2023

As planned and currently done in OpenSlides/openslides-proxy#4 the proxy will start responding with 413 when request payloads exceed (per default 250M) in size.

The client should handle this appropriately.
Imo a short message a snack box should suffice.

Also we could include the REQUEST_BODY_MAX_SIZE env var to the client. This way the client can also communicate the current limit to the user.
Alternatively we might want to have a statically-served-by-the-proxy route to get the limit. This would have to advantage of having to only restart the proxy when changing the limit.

@jsangmeister
Copy link
Contributor

Alternatively we might want to have a statically-served-by-the-proxy route to get the limit. This would have to advantage of having to only restart the proxy when changing the limit.

I'm not a fan of this. How often will this limit get changed? Probably very seldom. Sending a request to get that information seems overkill, especially since 1) every client has to do that 2) every x seconds/minutes to check if the limit changed, or otherwise the feature won't work as intended.

@jsangmeister
Copy link
Contributor

@peb-adr also please set the appropriate labels and milestones in future issues :)

@jsangmeister jsangmeister added this to the 4.1 milestone Aug 31, 2023
@peb-adr
Copy link
Member Author

peb-adr commented Aug 31, 2023

Alternatively we might want to have a statically-served-by-the-proxy route to get the limit. This would have to advantage of having to only restart the proxy when changing the limit.

I'm not a fan of this. How often will this limit get changed? Probably very seldom. Sending a request to get that information seems overkill, especially since 1) every client has to do that 2) every x seconds/minutes to check if the limit changed, or otherwise the feature won't work as intended.

I see your point, this is probably not the right way.
Another alternative would be to set an http header on the response conveying the limit. I think that should be a good way of doing it.

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

No branches or pull requests

4 participants