httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott Hutton <shut...@sputnik.com>
Subject Re: It's time to get 2.03-dev out
Date Fri, 11 Jun 2004 19:02:19 GMT
Sorry for the bad quoting--until recently, I was lurking via the web 
e-mail archive and don't have the original message to reply to:

    On 2004-06-05 at 14:23:37, Joe Schaefer wrote:

BUGS:

    - Strange bug when ssl is enabled & lots of fields are present: see
        http://marc.theaimsgroup.com/?t=107766265600001&r=1&w=2

    - Fix build automake/libtool/autoconf build system so it works
      properly on OSX & AIX.  FreeBSD cannot build httpd-apreq2 either,
      but there are too many problems with the current (May 2004)
      ports of the auto* tools for us to accomodate FreeBSD (yet).

    - The current API does not handle failed query_string parsing
      adequately (apreq_request does log an error message, but 
      there's no status code in the struct for users to interrogate).

One more for the list.  At least as of RC2, the bug mentioned in:

    http://marc.theaimsgroup.com/?l=apreq-dev&m=108609005217749&w=2

is still present.  I've been tracking it down.  I'm still testing 
against RC2 since I have it riddled with debugging code at this point, 
and no recent CVS commits seem to hit anything relevant to the bug.

A little more detail -- in an HTTPS request, as the form parameters are 
read, the first "upload" field encountered (i.e., one with a 
Content-Type header) appears to clear out all the former fields.  The 
only fields available to the application are the ones *following* the 
file upload part.

I've been tracking this through the code.  The BB structure passed into 
apreq_parse_multipart() appears to have already been corrupted.  In an 
SSL request, here's the flattened BB, as produced by the code snippet a 
the bottom of this message:

-----------------------------5007126436820676001099277657^M
Content-Disposition: form-data; name="action"^M
^M
Upload^M
-----------------------------5007126436820676001099277657--^M
ition: form-data; name="del_pcid"^M
^M
^M
-----------------------------5007126436820676001099277657^M
Content-Disposition: form-data; name="newimg"; filename="test.txt"^M
Content-Type: text/plain^M
^M
^M
----------------^M
-----------------------------5007126436820676001099277657^M
Content-Disposition: form-data; name="action"^M
^M
Upload^M
-----------------------------5007126436820676001099277657--^M
  


In a non-SSL POST to the same form:

-----------------------------16779119895875796761830306478^M
Content-Disposition: form-data; name="f"^M
^M
2^M
-----------------------------16779119895875796761830306478^M
Content-Disposition: form-data; name="del_pcid"^M
^M
^M
-----------------------------16779119895875796761830306478^M
Content-Disposition: form-data; name="newimg"; filename="test.txt"^M
Content-Type: text/plain^M
^M
My dog has fleas.
^M
-----------------------------16779119895875796761830306478^M
Content-Disposition: form-data; name="action"^M
^M
Upload^M
-----------------------------16779119895875796761830306478--^M

  

That's all I have for the moment.  Here's the debug code I used (it 
immediately follows the "mfd_parse_brigade" label).  Granted, this is my 
first foray into the wonderful world of APR bucket brigades, so consider 
appropriate disclaimers inserted:

    {
      char flat[40960];
      apr_size_t size = 40960;                                                           
                                                  
 
      if (apr_brigade_flatten(bb, flat, &size) != APR_SUCCESS) {
        SDEBUG("BB flatten failed!");
      } else {
        SDEBUG("BB flat = %s", flat);
      }
    }


More when I know more...

 -Scott

Mime
View raw message