Issac Goldstand <[EMAIL PROTECTED]> writes: > That's what I originally thought when told to do it this way, but its wrong. > RFC 3875 section 4.1.7 says > > The server MUST set this variable; if the Script-URI does not include > a query component, the QUERY_STRING MUST be defined as an empty > string (""). > > So it does need to be there, and therefore apreq_handle_cgi() won't > change the behavior *as long as* the CGI provider is RFC-compliant
Why not just use GATEWAY_INTERFACE? That way we don't need to argue about the actual adoption of RFC 3875 (not a standard) vs the original (ambiguous) CGI spec. >> (you can't assume the webserver is >> apache), and the docs for apreq_handle_cgi() currently suck: >> >> "Create an apreq handle which is suitable for a CGI program. It reads >> input from stdin and writes output to stdout." >> >> >> >From the documentation, I have no idea what that the specified behavior is >> supposed to be, other than to say the symbol should >> "work" in any CGI environment. (Not sure even why it claims to write >> anything to stdout, since we don't bake() cookies anymore). >> > Right. Are those docs generated by anything other than doxygen-ing > the source? > Maybe I can get some time (and find the patience) to try to spice them up a > bit... Yeah, it's all doxygen-generated. The symbol is in apreq_module.h I think. >> As a user, when I see lame documentation like that for a symbol in a >> released library, I assume the devs haven't gotten around to docmenting the >> current behavior- not that they haven't yet decided what the behavior >> should be. >> >> So, IMO the branch has a long way to go before it's suitable for merging >> into trunk. At a minimum it needs documentation and tests for the new >> behavior. You also need to decide if this stuff is a 2.x feature, in >> which case a new module (could bundle with libapreq alongside cgi) might >> be more appropriate. Or is it a 3.0 feature, in which case changing the >> behavior of apreq_handle_cgi() is ok > In my original post[1], I mentioned that I personally think a separate module > (enhanced_cgi?) might be smarter, but I got no response, so continued > development the way my boss wanted to have it done in-house, and > figured we can always split later. It's your call whether you want to do a new module, writing all the tests, docs and perl glue, or work with the existing cgi module. I think it's possible to work with the existing cgi module and incorporate the changes into the 2.x line, but it'd require *serious* documention work. You'd have to explain how people could get the old behavior back if they wanted it, (eg. by including the GATEWAY_INTERFACE env var for instance). -- Joe Schaefer