I suggest the following patch to avoid apr_size_t& to apr_off_t& :
Index: modules/lua/lua_request.c
===================================================================
--- modules/lua/lua_request.c (revision 1572748)
+++ modules/lua/lua_request.c (working copy)
@@ -321,9 +321,9 @@ static int req_parseargs(lua_State *L)
static int req_parsebody(lua_State *L)
{
apr_array_header_t *pairs;
- apr_off_t len;
+ apr_off_t size;
int res;
- apr_size_t size;
+ apr_size_t len;
apr_size_t max_post_size;
char *multipart;
const char *contentType;
@@ -339,8 +339,7 @@ static int req_parsebody(lua_State *L)
const char *data;
int i;
size_t vlen = 0;
- size_t len = 0;
- if (lua_read_body(r, &data, (apr_off_t*) &size, max_post_size) !=
OK) {
+ if (lua_read_body(r, &data, &size, max_post_size) != OK) {
return 2;
}
len = strlen(multipart);
@@ -376,10 +375,11 @@ static int req_parsebody(lua_State *L)
if (res == OK) {
while(pairs && !apr_is_empty_array(pairs)) {
ap_form_pair_t *pair = (ap_form_pair_t *)
apr_array_pop(pairs);
- apr_brigade_length(pair->value, 1, &len);
- size = (apr_size_t) len;
+ size = 0;
+ apr_brigade_length(pair->value, 1, &size);
buffer = apr_palloc(r->pool, size + 1);
- apr_brigade_flatten(pair->value, buffer, &size);
+ len = (apr_size_t)size;
+ apr_brigade_flatten(pair->value, buffer, &len);
buffer[len] = 0;
req_aprtable2luatable_cb(L, pair->name, buffer);
}
[END]
On Thu, Feb 27, 2014 at 10:59 PM, Daniel Gruno <[email protected]> wrote:
> On 02/27/2014 10:53 PM, Yann Ylavic wrote:
> > On Thu, Feb 27, 2014 at 8:10 PM, <[email protected]
> > <mailto:[email protected]>> wrote:
> >
> > Author: humbedooh
> > Date: Thu Feb 27 19:10:55 2014
> > New Revision: 1572703
> >
> > URL: http://svn.apache.org/r1572703
> > Log:
> > mod_lua: Only read up to whatever the user defines as max size when
> > using r:parsebody() - if content length is greater, return an error.
> >
> > Modified:
> > httpd/httpd/trunk/modules/lua/lua_request.c
> >
> > Modified: httpd/httpd/trunk/modules/lua/lua_request.c
> > URL:
> >
> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/lua/lua_request.c?rev=1572703&r1=1572702&r2=1572703&view=diff
> >
> ==============================================================================
> > --- httpd/httpd/trunk/modules/lua/lua_request.c (original)
> > +++ httpd/httpd/trunk/modules/lua/lua_request.c Thu Feb 27 19:10:55
> 2014
> > @@ -15,6 +15,8 @@
> > * limitations under the License.
> > */
> >
> > +#include <mod_core.h>
> > +
> > #include "mod_lua.h"
> > #include "lua_apr.h"
> > #include "lua_dbd.h"
> > @@ -228,7 +230,8 @@ static int req_aprtable2luatable_cb_len(
> > requests. Used for multipart POST data.
> >
> >
> =======================================================================================================================
> > */
> > -static int lua_read_body(request_rec *r, const char **rbuf,
> > apr_off_t *size)
> > +static int lua_read_body(request_rec *r, const char **rbuf,
> > apr_off_t *size,
> > + apr_off_t *maxsize)
> >
> >
> > Shouldn't maxsize not be a pointer?
> Maxsize should just be a plain ol' number - thanks for pointing that out :)
> >
> >
> >
> > {
> > int rc = OK;
> >
> > @@ -243,6 +246,9 @@ static int lua_read_body(request_rec *r,
> > apr_off_t length = r->remaining;
> > /*~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~*/
> >
> > + if (maxsize != 0 && length > maxsize) {
> > + return APR_EINCOMPLETE; /* Only room for incomplete
> > data chunk :( */
> > + }
> > *rbuf = (const char *) apr_pcalloc(r->pool, (apr_size_t)
> > (length + 1));
> > *size = length;
> > while ((len_read = ap_get_client_block(r, argsbuffer,
> > sizeof(argsbuffer))) > 0) {
> > @@ -336,7 +342,7 @@ static int req_parsebody(lua_State *L)
> > int i;
> > size_t vlen = 0;
> > size_t len = 0;
> > - if (lua_read_body(r, &data, (apr_off_t*) &size) != OK) {
> > + if (lua_read_body(r, &data, (apr_off_t*) &size,
> > max_post_size) != OK) {
> >
> >
> > IMHO, there really should be no cast needed here.
> It's cast because the two different options that depend on max size want
> two different types, so I cast it in one point and pass it as an
> apr_size_t in another. Suggestions are as always most welcome.
>
> With regards,
> Daniel.
>
