[FYI] rewrote gwlib/http.c:parse_url()

Hi list,

I just commited this to cvs head tree:

2003-08-01  Stipe Tolj  <[email protected]>
    * gwlib/http.[ch]: rewrote parse_url() to parse the URL into an 
      HTTPURLParse struct that holds all relevant components of an
URL, ie.
      scheme, hostname, port, etc. Added therefore
http_urlparse_create() and
      http_urlparse_destroy(). Now parse_url() is not populating given 
      variables, but does return an HTTPURLParse pointer to the
caller, so
      the caller can grep for the required information. Routine
parse2trans()
      has also been added to allow internal mapping of the
HTTPURLParse 
      struct to the HTTPServer struct and the corresponding URL
components.
      This rewrite *should* not change HTTP client behaviour. Removed
unused
      parse_url_path() because this can be done now via parse_url()
and the 
      resulting struct. Added 'conn_time' to HTTPClient struct. This
will
      be our future timeout reference for letting the keep-alive
sessions
      die if a certain timeout is reached. Currently we *never*
destroy 
      reseted HTTPClient's, which is a possible security
consideration.
      We need to implement an cleaner_thread() that drops all idle
keep-alive
      connections.

which means parse_url() does now only take the url as argument itself
and returns an HTTPURLParse structure containing the parsed
components:

typedef struct {
    Octstr *url;
    Octstr *scheme;
    Octstr *host;
    unsigned long port;
    Octstr *user;
    Octstr *pass;
    Octstr *path;
    Octstr *query;
    Octstr *fragment;
} HTTPURLParse;

so the caller of parse_url() can decide on return this component
he/she needs further processing.

I have tested this with a lot of URLs, please update your cvs tree and
try if you can break it. Please complain ASAP, so we can have our
hands back again on it.

BTW, the cleaner_thread() I mentioned above is used to destroy idle
HTTPClient connections that are "waiting" on further input, but
apparently should be timeout'ed. Otherwise someone can do an simple
DOS attack by opening as many sockets as Kannel's HTTP server allows.

Stipe

[email protected]
-------------------------------------------------------------------
Wapme Systems AG

Vogelsanger Weg 80
40470 Düsseldorf

Tel: +49-211-74845-0
Fax: +49-211-74845-299

E-Mail: [email protected]
Internet: http://www.wapme-systems.de
-------------------------------------------------------------------
wapme.net - wherever you are