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
