Joe Schaefer wrote:
Issac Goldstand <[EMAIL PROTECTED]> writes:Philip M. Gollucci wrote:[...]Sadly, I don't think this can go into the 2.x series because of our conversioning rules. New features need new symbols. SVN gets around this by doing: void foo (void) void foo2 (int)Can you elaborate? I didn't understand that bit.The branch changes the behavior of apreq_handle_cgi(). The CGI specsmake no guarantee about the existence of a QUERY_STRING env var when the url doesn't contain a "?"
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
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...(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 readsinput 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).
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 theIn 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. Regarding tests for this, now that the subject seems to have attracted some interest, does anyone have any suggestions on how to best test this? Since the point is to communicate interactively via STDIN/STDOUT, I'm not sure how to best test it (beyond making sure that the existing CGI tests don't break - they currently don't)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
Issac [1] http://marc.theaimsgroup.com/?l=apreq-dev&m=116004301004962&w=2
