httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <joe+gm...@sunstarsys.com>
Subject Re: query string parser
Date Mon, 26 Jan 2004 14:39:04 GMT
"Nir Shahaf" <nir_sh@magnifire.com> writes:

> Hi,
> I'm new in this list and I have a quick question. I'm writing a module
> using libapreq. I'm using the apreq_request function. I've noticed that
> when supplied with an non-RFC compliant query string, 
                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Query strings are really opaque from an RFC standpoint.  The urlencoded
name-value pairs are IMO just a common convention, one that libapreq
assumes will hold.  However, if it doesn't, that shouldn't cause
libapreq to fail entirely, since an application may only need libapreq
for parsing the POST data.

Now if apreq_decode_param() cannot make sense of a name-value pair, 
it'll return a param with a non-APR_SUCCESS status, which should cause
apreq_parse_query_string() to abort, returning the param's
(non-APR_SUCCESS) status code.

> the parser fails, but the error code is not sent to the calling
> function. 

Currently apreq_request() should write something to the error log
in this circumstance.  Does it actually do that?

> My problem is that my module can't know whether the parsing failed or
> no parameters were found (in both cases I get an empty table of
> parameters). Is there a reason why this function doesn't return error
> codes?

I'm not sure how apreq_request() should be modified to make it
available.  I agree it'd be nice to provide this info to your
application.  Any suggestions?


-- 
Joe Schaefer


Mime
View raw message