3 ms·

> RFC 3875 (CGI) puts the HTTP Proxy header from a request into the environment variables as HTTP_PROXY I don't get it, so if I use CGI, and from my code, I qu

> RFC 3875 (CGI) puts the HTTP Proxy header from a request into the environment variables as HTTP_PROXY I don't get it, so if I use CGI, and from my code, I query the env variable named 'HTTP_PROXY' , I will get what was set by the request header PROXY and not an environment variable 'HTTP_PROXY' as defined by the system the cgi executable is running on ? edit : I looked at CGI https://en.wikipedia.org/wiki/Common_Gateway_Interface https://en.wikipedia.org/wiki/Common_Gateway_Interface I don't understand why this protocol just doesn't pass informations as an argument for the cgi script, why does it have to use environment variables ?

mwpmaybe 10y ago
Correct.
deleted 10y ago
[deleted]
pfg 10y ago
If your question is regarding the precedence of the Proxy header vs. an environment variable, I'm not sure which of the two would win, but even if it's the latter, anyone who doesn't set it (which is probably the majority) would still be vulnerable.
- mwpmaybe 10y ago
  CGI implementations will take the value of the Proxy header and clobber whatever might have originally been set in the environment at HTTP_PROXY.
tantalor 10y ago
That's how CGI works. > pass informations as an argument for the cgi script Elaborate?
deleted 10y ago
[deleted]
honkhonkpants 10y ago
Passing data as arguments is even more dangerous, especially when the program is a shell.
- spriggan3 10y ago
  Good point. Well at least namespace data correctly , or dump the request, headers + body in a single CGI env variable.
  - toast0 10y ago
    CGI did namespace these headers correctly: headers X becomes HTTP_X. The problem is that the outgoing proxy config variables aren't PROXY_X, they're X_PROXY. (Other env variables from CGI aren't namespaced, however) Dumping the headers into a single env variable means a) you need to have support for pretty big environment variables which probably wasn't realistic in 1993; b) every program that wants to use headers needs to know how to parse them, which is tricky. Dumping the body into an env variable is bad because any reasonably sized body is not going to fit, and you really want the program to be able to start working on it before it completes.
toast0 10y ago
Arguments would be trickier, as escaping/quoting requirements aren't universal, and some environments (especially in 1993) have a pretty limited argument space; there is a non-parsed-header mode for CGI that passes the headers through to the CGI on stain be for the body which is maybe a better way. Environment variables are also convenient if you only care about headers deep inside many layers of code -- it would be tricky to parse the command line there, but grabbing the environment variables is simple.
riobard 10y ago
Script arguments are not standardized (various ways to access and different conventions). Environment variables are pretty universal. It's one of the reasons that 12-Factor App guide recommends env vars for configuration.

mwpmaybe 10y ago

Correct.

deleted 10y ago

[deleted]

pfg 10y ago

If your question is regarding the precedence of the Proxy header vs. an environment variable, I'm not sure which of the two would win, but even if it's the latter, anyone who doesn't set it (which is probably the majority) would still be vulnerable.

mwpmaybe 10y ago
CGI implementations will take the value of the Proxy header and clobber whatever might have originally been set in the environment at HTTP_PROXY.

tantalor 10y ago

That's how CGI works. > pass informations as an argument for the cgi script Elaborate?

deleted 10y ago

[deleted]

honkhonkpants 10y ago

Passing data as arguments is even more dangerous, especially when the program is a shell.

spriggan3 10y ago
Good point. Well at least namespace data correctly , or dump the request, headers + body in a single CGI env variable.
- toast0 10y ago
  CGI did namespace these headers correctly: headers X becomes HTTP_X. The problem is that the outgoing proxy config variables aren't PROXY_X, they're X_PROXY. (Other env variables from CGI aren't namespaced, however) Dumping the headers into a single env variable means a) you need to have support for pretty big environment variables which probably wasn't realistic in 1993; b) every program that wants to use headers needs to know how to parse them, which is tricky. Dumping the body into an env variable is bad because any reasonably sized body is not going to fit, and you really want the program to be able to start working on it before it completes.

toast0 10y ago

Arguments would be trickier, as escaping/quoting requirements aren't universal, and some environments (especially in 1993) have a pretty limited argument space; there is a non-parsed-header mode for CGI that passes the headers through to the CGI on stain be for the body which is maybe a better way. Environment variables are also convenient if you only care about headers deep inside many layers of code -- it would be tricky to parse the command line there, but grabbing the environment variables is simple.

riobard 10y ago

Script arguments are not standardized (various ways to access and different conventions). Environment variables are pretty universal. It's one of the reasons that 12-Factor App guide recommends env vars for configuration.