Create functions for URL parsing about picohttpparser HOT 7 CLOSED

@anatol found another uri parser which is like phr, it is based on the NGINX and Node parser. https://github.com/Zewo/uri_parser

from picohttpparser.

Let me know what do you think about this idea.

If you think url parser should be different project independent of H2O then I might start looking at implementing it. Most likely with Ragel state machine compiler and picohttpparser-like API.

from picohttpparser.

Interesting.

However I wonder if it would be a easy task to reach consensus upon how a query parsing API should be designed. Won't people want to use different structures for storing the key-value pairs of a query?

The concern makes me think that the best way for you to go forward is to create a separate repository for implementing a query parser that most fits your need, and then show it to others.

How does it sound?

from picohttpparser.

Won't people want to use different structures for storing the key-value pairs of a query?

This is going to be the the same key-value structure as used for headers in http parser. The name could be either keyvalue of queryparams (I like the keyvalue).

from picohttpparser.

This is going to be the the same key-value structure as used for headers in http parser. The name could be either keyvalue of queryparams (I like the keyvalue).

Well, that is the point I cannot agree / is the reason why I suggested you should better create a separate library for parsing queries.

I am not sure if it is practical to expect that the upper bound of the number of key-values pairs in a query is relatively small (as is the case for the HTTP headers). IMO it is hard to expect the upper bound in case of queries, and therefore the query parser should either dynamically allocate memory or call a callback to allocate memory. It might also be necessary to use a non-O(n) structure for searching a key within the pairs (i.e. use hashtable for storing key-value pairs).

from picohttpparser.

I am not sure if it is practical to expect that the upper bound of the number of key-values pairs in a query is relatively small

Well, in practice URI length is limited. Most browsers think that URI should not be longer than 2048 symbols and it is good enough hard upper bound for query params. i.e. we can expect that there will no be more than 1000 params in the URI.

But my idea that I had in mind is parser returns an error if number of params is larger than provided structure (like in your http parser). In this case user can reparse the URI with bigger array.

Okay, here is real quick implementation for this idea https://github.com/anatol/uriparser

from picohttpparser.

Thank you for elaborating.

I still believe that it should be implemented as a separate library (or in other words there is no necessity that URL parsing should be implemented within picohttpparser).

from picohttpparser.