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 <ni...@freehaven.net> wrote: > On Thu, Dec 30, 2010 at 8:21 PM, Mihai Draghicioiu > <mihai.draghici...@gmail.com> 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 majord...@freehaven.net with > unsubscribe libevent-users in the body. > *********************************************************************** To unsubscribe, send an e-mail to majord...@freehaven.net with unsubscribe libevent-users in the body.
