httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <>
Subject [multi-env] privatizing apreq_request_t and apreq_jar_t
Date Wed, 26 Jan 2005 03:17:36 GMT
Joe Schaefer <> writes:

> Max Kellermann <> writes:
> [...]
>> - remove the second parameter from apreq_request() and apreq_cookie()
> Actually, where I see the handle/module concepts 
> heading is to the privatization of apreq_jar_t and 
> apreq_request_t.

Now let's try to remove apreq_request_t and apreq_jar_t from 
the multi-env branch.  My basic idea is to remove those public 
structs, and to replace the current apreq_env_module_t accessors

-   apreq_jar_t *(*jar)(apreq_env_handle_t *, apreq_jar_t *);
-   apreq_request_t *(*request)(apreq_env_handle_t *, apreq_request_t *);

with something simple:

+   apr_status_t (*jar)(apreq_env_handle_t *, const apr_table_t **);
+   apr_status_t (*args)(apreq_env_handle_t *, const apr_table_t **);
+   apr_status_t (*body)(apreq_env_handle_t *, const apr_table_t **);
+   apreq_cookie_t *(*cookie)(apreq_env_handle_t *, const char *);
+   apreq_param_t *(*query_param)(apreq_env_handle_t *, const char *);
+   apreq_param_t *(*body_param)(apreq_env_handle_t *, const char *);

The upside is that we only expose a const apr_table_t now, 
so libapreq2 users can't do any unsafe operations on that.
And we still maintain the "get-all" vs. "get-first" 
semantics on the body params, so lazy parsing works ok.

The downside is that some Apache::Request users will still 
want to modify those tables (not just fields within the 
individual table entries), so we might need to include 
the missing add|set|delete table operations for each 
(jar,args,body. Otherwise we let each env module decide 
to support (or not) the missing functionality through its 
own API.

Any thoughts on this?

Joe Schaefer

View raw message