These larger buffer sizes accommodate larger requests that are often complained about in Valet support issues.
These updates are inspired by common configs in Homestead.
I've been using these in my local Valet config for 4+ months, without any negative side-effects.
Edit: commented-out several, and made consistent with Forge defaults
A long-requested adjustment to Valet is to bypass the logging of robots.txt and favicon.ico hits. Particularly when keeping an Ngrok session alive.
This update is consistent with default logging settings in Forge.
Fixes#772
I've been using this config change since Aug 17, 2019, without any negative side-effects.
All Valet services continue to work properly, and Valet Share still works just as expected.
If someone were to have a challenge with it, there's an easy downgrade: just remove the `127.0.0.1:` from these files, and run `valet tld test` to rebuild the individual site configs. Or just manually edit the `~/.config/valet/Nginx` site file manually.
client_max_body_size does not propagate down from the http context into
the server context.
See this stack overflow for further details on the issue:
https://stackoverflow.com/questions/2056124/nginx-client-max-body-size-has-no-effect
This fix ensures that the max client body size is always the default
128mb as specified in nginx.conf.
- Sets `client_max_body_size 128M` in `http` section of `nginx.conf` so it covers all configs
- Adds `php-memory-limits.conf` to `php-fpm` conf folder, to set `memory_limit`, `upload_max_filesize`, `post_max_size` all to 128M
(Updates #253 by moving config location to cover all, since #253 didn't cover secure configs, etc)
When retrieving the query string in your app, it's twice the value it should be.
For example I have a request like "/overview?page=1" when I use request()->server('QUERY_STRING') I get "page=1&page=1" instead of "page=1".
Removing the ?$querystring for the Nginx config in the rewrite directive fixes this.
