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 Caddyfile support for request_body #3859

Merged
merged 5 commits into from
Nov 16, 2020

Conversation

pic
Copy link
Contributor

@pic pic commented Nov 8, 2020

  request_body {
    max_size 10000000
  }

See: https://caddy.community/t/file-upload-size-limits/8419

```
  request_body {
    max_size 10000000
  }
```
@CLAassistant
Copy link

CLAassistant commented Nov 8, 2020

CLA assistant check
All committers have signed the CLA.

@pic
Copy link
Contributor Author

pic commented Nov 8, 2020

@mholt
It's a copy / paste / adapt effort. I'm a complete beginner in go. Any feedback is appreciated, thx.

rb := new(RequestBody)

for h.Next() {
// if not, they should be in a block
Copy link
Member

Choose a reason for hiding this comment

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

This comment doesn't really make sense because the only thing being parsed is max_size.

You should reject unknown fields (you can use a switch statement with a default that returns an error). You should also reject any additional args on the same line (if we decide to only configure this via the block option, see below)

I'm not convinced that the only way to configure this should be via a block, because it only has one option. For example, the directive might be max_request_body_size <size> instead.

But on the other hand, aligning it with the JSON config isn't a bad idea either. It's just that we might never have any other options than just max_size, so it feels kinda strange to require a block.

I'm of two minds about it.

Anyways, the actual syntax as written would be:

request_body [<matcher>] {
	max_size <size>
}

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yes, exactly. Should I change to max_request_body_size or do we keep it this way?

Copy link
Member

Choose a reason for hiding this comment

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

I'm not sure. I'll let @mholt chime in. I'm leaning towards keeping it as-is but I wanted to bring up the point of discussion.

Copy link
Member

Choose a reason for hiding this comment

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

I think this is a less-commonly-used feature, so we're probably fine with the more verbose syntax for now. It also lets us add more options like replacements (etc.) in the future.

@francislavoie
Copy link
Member

Also please don't forget to sign the CLA. If you already did but it's not recognizing it, it might be that you committed have a different email address than you have attached to your GitHub account. Please add that email to your GitHub account if so.

@francislavoie
Copy link
Member

Oh - also please add an adapt test, see here: https://github.com/caddyserver/caddy/tree/master/caddytest/integration/caddyfile_adapt just make a new file that has a minimal Caddyfile, then a separator with 10 - chars, then the JSON output of caddy adapt --pretty.

@pic
Copy link
Contributor Author

pic commented Nov 10, 2020

@francislavoie 👍 , done.
Let's see about the Caddyfile syntax discussion.

Copy link
Member

@mholt mholt left a comment

Choose a reason for hiding this comment

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

Thank you! This actually looks pretty good. And it's a simple improvement, which we like. Happy to accept this.

Thanks for your contribution! If you have a moment, would appreciate some help updating the docs for this new directive for our website too: https://github.com/caddyserver/website

@mholt mholt merged commit 670b723 into caddyserver:master Nov 16, 2020
@mholt mholt added this to the v2.3.0 milestone Nov 16, 2020
@pic
Copy link
Contributor Author

pic commented Nov 18, 2020

@mholt thanks for merging,
here the PR for the website: caddyserver/website#104

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.

4 participants