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 Re: proposed 2.0 features/layout (was Re: starting apreq 2.0)
Date Thu, 31 Jan 2002 23:27:49 GMT
Issac Goldstand <margol@beamartyr.net> writes:

> Maurice Aubrey wrote:
> >
> >I think the idea is to just have a function, something
> >like apreq_register_enctype(), that accepts an enctype and
> >a function pointer.  And when a request is ready to be
> >parsed it will look up the enctype in that table and call
> >the appropriate function(s).

That's exactly what I had in mind.

> So it would be registered at apache startup using a callback in some 
> other apache module?  

No.

> If not, what's going to register the function?  

Presumably, the user writes something like this

  apreq_request_t *apr = apreq_request_new(r, with_some_flags);

  areq_request_parser_t *foo = /* some appropriate function pointer */;

  apreq_register_enctype(apr, "application/sgml-form-urlencoded", foo,
                                (void *)parser_data );

  apreq_request_parse(apr); /* this calls foo(apr, parser_data) to parse
                                sgml-encoded input */

> If so, does that mean that an apache module has to be created for each
> enctype (or "bundle" of enctypes)?

No, after settling on the names and features, we just stick
apreq_register_enctype and apreq_request_parser_t in a .h file 
and implement them.  We keep a dispatch table of enctypes somewhere 
in the apreq_request_t struct (installing the default enctypes
via the apreq_request_new() call).

It's conceptually similar to how we implemented the UPLOAD_HOOK
flag in Apache::Request.  The logic for it is mostly carried out in 
apache_request.c, and it was David Welton's idea to do it that way.  
All I'm really suggesting is that we run with it a little further 
and push the whole parsing activity into an external function.

-- 
Joe Schaefer


Mime
View raw message