introduce profile setting to gunicorn

[benoitc]

It's unfortunate that people don't understand when talk about security in Gunicorn. When Gunicorn is used as a WSGI server it shoudl comply as much as possible with the specification. (Even it's slightly relaxed for streaming content as of today). For example some environ variables are required: https://peps.python.org/pep-3333/#environ-variables and for Error handling in general the applications should trap their own internal error : https://peps.python.org/pep-3333/#error-handling

As for gunicorn I think that we should provide 2 modes:

1. is running behind a proxy/HTTP server . In this case some secuirtiy could be relaxed and CGI variables, probably Forwatd shuoudl be passed and secured from this server . This is the advised way until now.
2. gunicorn acting itself as main server. In such case we should ensure only Gunicorn and system env can set this variables .

A simple --profile setting set as server or gateway could enforce some rules and options. ie. no CGI-VARIABLES should be accepted when it's come from HTTP in server profile. These variables can only be set using OS env or configuration in such case. In gateway mode we should probably accept them transparently and let the security beeing handled by the server on top.

[pajod]

PATH_INFO and SCRIPT_NAME are required

I do not think there is any doubt about them being required in environ, and them being required to produce a sensible URL when combined back together. My remaining question was rather: if we did not permit that for some time anyway, are we required to give the user the flexibility to dynamically set the latter to anything other than the most trivial value: the remainder of the path after removing the SCRIPT_NAME from the front (which we unconditionally set now)?

A simple --profile setting set as server or gateway could enforce some rules and options

But what meaningful difference in rules could that enforce, when headers are restricted based on where they originate from anyway? Is there a use case for distinguishing between receiving no further configuration.. and receiving no further configuration while based on the defaults theoretically prepared to take it?

[benoitc]

@pajod the main idea to reduce the complexity at the very beginning for the users. We have way too much options that need to be explained as of today. Setting a profile would set the expectations.

More generally I think we let too much flexibility in our settings as of today. This may be good for advanced users but makes the experience harder for others . This also makes the support more complicated. We need to revisit the settings and our documentation ASAP.

Note: in production in production, people that take care of hardeniing their env have already wsgi middleware that enforce the rule for headers and same for other parts of the spec like partial bodies. I am thinking that we could also bring this as an higher level since frameworks are more an more hiding this simplicity .

[pajod]

We have way too much options that need to be explained

@benoitc I think we can address part of that by moving, hiding and/or de-emphasizing the documentation for deprecated or temporary ones, see #3272