Re: [RELEASE CANDIDATES] Status ?

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