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 steps to libapreq 1.0
Date Wed, 27 Jun 2001 16:20:26 GMT
Perhaps it's time for an open discussion of what's wanted, 
and needed, for apreq to bring it to a 1.0 version.

Personally I'd like to see a 1.0 release before
the end of summer, and I think the 1.x series should
be for use with apache 1.x and modperl 1.x.  IMO 
porting to apache 2 should be reserved for a 2.x release.

Assuming that is palatable to everyone, what features
in the current C API are missing / needed?  ISTR the 
current cookie support was not yet RFC 296[45] compliant.
I'd like to automate the perl+SFIO support (just needs some
autodetection), rework the multipart_buffer code to
incorporate list.[ch], and use it to possibly add support 
for uploading chunked data.  I think this would be a nice
feature to have, since it's impossible to parse chunked
data over a CGI 1.1 interface.

Here's a few comments on the current ToDo file:

          TODO                                      COMMENTS

o look for 'XXX' in the source, they mark     PerlIO_importFILE ?                        
                                
  some bits of code that need work              

o port to apache 2.0                          reserve for a 2.0 release

o multipart_buffer_headers punts on headers   list.[ch] will do this
  more than 5k (which could happen with a 
  really long form input name, for example). 
  better than the old behavior of locking up, 
  but we could be clever and actually handle 
  this.

o should probably handle                      don't understand ??
  Apache::Request->param http://blah.com/?foo 
  like CGI.pm does (turn it into a param 
  named "keywords")

o Perl's FILE* typemap leaks!                 For which perl versions? Are
                                              you sure it's not GLOBS
                                              that are leaking? If so, perhaps 
                                              we can do something "smarter"
                                              (a'la do {local *FILE})
                                              in the CLEANUP section
                                              of Request.xs: ApacheUpload_fh?

o libapreq.so                                 For C module authors? If
                                              so, a good idea. How's
                                              the current autoconf support?

o mmap upload files                           Portability?

o investigate USE_MY_TMPNAME more             Done?

o ApacheHTML?                                 Don't like this idea.

o for mod_dtcl, it may be good to allow a     Done.
  callback function for storing file uploads 
  (since it is configurable to store the
  uploads in memory instead of to disk)

o allow the directory for temporary files     Done.
  to be specified? we currently use tmpfile(), 
  though, and we'd have to do a secure
  temp-file-creating function to do this.



What are your thoughts?

-- 
Joe Schaefer



Mime
View raw message