httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <joe+apa...@sunstarsys.com>
Subject [rfc] some thoughts for apreq-2
Date Fri, 03 Jan 2003 03:42:30 GMT

After experimenting with a few different designs 
regarding new data apreq-2, I've settled on the
following concepts for our new data structures:

  1) apreq_tables will be the common data structure
     for both req->param and apreq_cookie_jar.  apreq_tables
     still return a char* via apreq_table_get(), but it's an 
     "enhanced" char*...

  2) the apreq_value_t is the (extensible) internal struct for the 
     table values:
  
     struct apreq_value_t {
        apr_ssize_t  size;
        char         data[1];  /* see comp.lang.c FAQ #2.6 */
     }    

     apreq_table_get() returns a pointer to the "data" string;
     the size attribute is obtainable through ANSI C's offsetof().

   3) parsers will extend apreq_value_t by placing it at the
      *end* of their own structs, since the tail of apreq_value_t
      is reserved for the data itself.

Although these choices may seem strange at first, I think they 
offer a good compromise between backwards compatibility, speed,
and a better string type for applications that need it.

Originally I was considering using apreq_value_t * throughout
the apreq_table API, but it made the API too cumbersome for
*typical* usage (I felt there was too much pointer checking & 
dereferencing).

Here's how I'm planning to use it for apreq_cookies:

  struct apreq_cookie_t {
      char *name;
      char *value;  /* typically points to v.data (see below) */
      char *path;
      char *domain;

      int   max_age;
      char *comment;
      char *commentURL;
      char *port;
      char  secure;

      apreq_cookie_version_t version; /* XXX does this belong here? */

      char *pool;
      apreq_cookie_encode_t *encode;
      apreq_cookie_decode_t *decode;
      void *cache;               /* decoded value (cached) */
      unsigned char sync;        /* coordinate state of value and cache */
      apreq_value_t v;           /* original "raw" value */
  };

We parse the incoming "Cookie" header (via apreq_cookie_parse) into a 
cookie_jar, which is just an apreq_table with enhanced values. This 
makes the API for fetching raw cookie values extremely simple:

  apreq_cookie_jar_t *jar = apreq_cookie_parse(r, NULL);
  const char *my_cval = apreq_table_get( jar, "mycookie" );
  /* decode my_cval... */

Since we only need to parse the "Cookie" header once per
request, I think we should store a pointer to the jar in
r->notes, presumably using "apreq_cookie_jar" as key.  

I also plan to use r->notes for storing a pointer to our
apreq_filter, unless someone has a better idea.

Comments?
-- 
Joe Schaefer

Mime
View raw message