Re: [Libevent-users] bug + question

[Mihai Draghicioiu <mihai.draghicioiu@xxxxxxxxx>]

Thanks Nick!

Well, with PHP, you can have parameters of these forms:

foo=bar&baz=quux
foo=bar&baz= (empty baz)
foo=bar&baz (empty baz)

they all work, but in the last two cases, the value of baz is an empty string.
And I was just thinking the parser can be a bit loose, without this
generating any trouble. I wasn't thinking of any standard.

On Wed, Jan 5, 2011 at 9:16 PM, Nick Mathewson <nickm@xxxxxxxxxxxxx> wrote:
> On Thu, Dec 30, 2010 at 8:21 PM, Mihai Draghicioiu
> <mihai.draghicioiu@xxxxxxxxx> wrote:
>> Hi all. I've found that evhttp_parse_query_str only works if the query
>> string is of the form foo=bar&baz=quux. If we have a query string of
>> the form foo=bar&baz (no value for the last key), it fails. I consider
>> this a bug, because you have all the other valid parameters in there,
>> and it can just set NULL for the value of the baz parameter. I believe
>> the behavior of evhttp_parse_query() is different (correct). I had
>> used evhttp_parse_query() until now, and switched to
>> evhttp_parse_query_str() and discovered this bug.
>
> I'll repost my question from
> https://sourceforge.net/tracker/?func=detail&aid=3037662&group_id=50884&atid=461322
> :
>
> ===
> So, RFC3986 says that the query part of a URL can be any sequence of
> characters in a given set, without providing any instructions on how to
> encode or decode them.
>
> The only place that i can find the key=val&key2=val2 format expressed, on
> the other hand, is in the HTML standard, which doesn't define anything
> about parameters without values.
>
> So I'm inclined to say that this is not-a-bug: If the query parameters are
> not encoded in the HTML-standard way, then absent some other standard, then
> decoding the Request-URI from the Request-Line is up to the library user,
> right?
>
> Is there a standard I'm missing here?
> ===
>
> In other words, according to what standard is foo=bar&baz to be
> interpreted? ÂIf we're considering generic URIs, there is no
> particular interpretation to the query part. ÂIf we're considering GET
> requests generated by HTML forms, I think it's invalid, if I'm reading
> the HTML spec right. ÂSo according to what standard does foo=bar&baz
> have an interpretation?
>
>> Second, I have a question - does one need to evhttp_uri_free() the
>> returned pointer from evhttp_request_get_evhttp_uri()? It crashes if I
>> do free it, so i'd like to make sure it's correct to not free it (no
>> memory leaks).
>
> Right. Â(In fact, you shouldn't be able to write correct code that
> tries to free it! ÂThe evhttp_request_get_evhttp_uri() function
> returns a const pointer, and evhttp_uri_free() requires a non-const
> pointer.)
>
>> Also, is the evkeyvalq usage in this example correct? Note that it
>> includes the issues described above:
>>
>> static void httpcb(struct evhttp_request *req, void *arg) {
>> Â Âevkeyvalq query; // is it meant to be used in this way?
>> Â Âevhttp_parse_query_str(evhttp_uri_get_query(evhttp_request_get_evhttp_uri(req)),
>> &query);
>
> Hm. ÂThis is a little iffy, since evhttp_uri_get_query can return
> NULL, and evhttp_parse_query_str is not documented to accept NULL.
> (It can and does, but I'd still call usage of an undocumented feature
> questionable.)
>
> Also, you aren't checking the return value of evhttp_parse_query_str.
>
>> Â Âconst char *val;
>> Â Âif((val = evhttp_find_header(&query, "command"))) {
>
> Looks fine to me.
>
>> Â Â Â Â...
>> Â Â}
>> }
>
>
> yrs,
> --
> Nick
> ***********************************************************************
> To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
> unsubscribe libevent-users  Âin the body.
>
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.