httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <>
Subject Re: multiple files with the same name, .h file changes
Date Wed, 20 Jun 2001 17:32:48 GMT (David N. Welton) writes:

> +
> +#define ApacheUpload_FILE(upload) (upload->fp)
> +
> +#define ApacheUpload_size(upload) (upload->size)
> +
>  #define ApacheUpload_info(upload, key) \
>  ap_table_get(upload->info, key)
> _FILE could be _fp too.  It's more consistent, but less descriptive.

Looks ok to me- I have no opinion on which of _FILE or _fp is 

> Second thing... I'm puzzling over how to implement code to handle
> multiple files uploaded with the same variable name.  It *is* legal,
> and it's a pain in the ass.  apreq has some problems with it:
> ApacheUpload *ApacheUpload_find(ApacheUpload *upload, char *name);
> which will only get the first one.
> I'd be curious to hear, briefly, how you perl guys deal with this, as
> well as if you have any ideas on how we can (if needs be) improve
> apreq to support this.

We provide a means to iterate over the upload table in Request.xs.  
Here's a snippet from Request.xs (xs files are mostly C code with some
perl glue macros):

	for (uptr = req->upload; uptr; uptr = uptr->next) {

This builds a return list of upload table entries, which the user
would get at by calling

  @upload_list = $apr->upload; # list context

We also offer a perl API to upload->next, so the user can iterate 
over the upload objects themselves:

  # $apr->upload called in scalar context returns first upload object

  for ( my $up = $apr->upload; $up; $up = $up->next ) {
    # check $up->name, $up->filename, etc.

We use a more user-friendly approach for multi-valued parameters, 
though. If the form has many values for the parameter "key", then
the user can get at them all by

  @values = $apr->param("key"); # list of values

The relevant code in Request.xs is around lines 415 - 430. We could
do something similar with $apr->upload("key"), but we currently don't.

Joe Schaefer

View raw message