Re: ap_log_rerror limit size
well, I do not buy the idea of security reasons, but I agree with your last
sentence that they do not see the need to make this a configurable option,
the error log does not need it.
regarding my purpose: mod_dumpio dumps data into the error log file in
chunks, I want to merge them if the message is large and do something with
it before logging. With this limitation, I will need to write it to
somewhere else using my custom file handler.
Vu
On Wed, Mar 13, 2013 at 5:46 PM, wrote:
> On Wed, Mar 13, 2013 at 04:40:50PM +0100, Hoang-Vu Dang wrote:
> > I traced this into the Apache source code (ver 2.4.4). It looks like the
> > error message string is really limited by the size of 8KB.
> >
> > This line is in server/log.c:1097
> >
> > "
> > static void log_error_core(const char *file, int line, int module_index,
> >int level,
> >apr_status_t status, const server_rec *s,
> >const conn_rec *c,
> >const request_rec *r, apr_pool_t *pool,
> >const char *fmt, va_list args)
> > {
> > char errstr[MAX_STRING_LEN];
> > "
> >
> > "
> > And MAX_STRING_LEN is defined in include/httpd.h:298
> >
> > /** The default string length */
> > #define MAX_STRING_LEN HUGE_STRING_LEN
> >
> > /** The length of a Huge string */
> > #define HUGE_STRING_LEN 8192
> > "
> >
> > I tried to increase this value, recompile, and apparently I got a longer
> > message.
> > Please correct me if I am wrong... If this is true then can anyone tell
> me
> > why this "HUGE_STRING_LEN" value is a hard-coded value but not a
> > configurable option ?
>
> I can't speak for the apache core team, but such a limit usually is done
> for security reasons. Tracking buffer overflows in dynamically allocated
> memory can be rather tricky. Btw, what's your goal here? I get the
> feeling that you try to (ab)use the error log as a place to dump large
> blobs of information (traces?). Remember, this is an error log, not a
> place to dump Tolstoy's War and Peace
>
> HTH Ralf Mattes
>
>
> > Cheers, Vu
> that you try to (ab)use the error log as a place to dump large blobs of
> information (traces?). Remember, this is an error log, not a
> place to dump Tolstoy's War and Peace
>
> HTH Ralf Mattes
> >
> >
> > On 03/13/2013 11:16 AM, Eric Covener wrote:
> >> On Wed, Mar 13, 2013 at 6:01 AM, Hoang Vu Dang
> wrote:
> >>> Hi guys,
> >>>
> >>> Is there any limit of the size of a message log entry? How to control
> >>> this ?
> >>>
> >>> I did this:
> >>>
> >>> ap_log_rerror(APLOG_MARK, APLOG_INFO, 0, f->r,
> >>> "%s", buffer);
> >>>
> >>> And the buffer was truncated on the error log. I check the strlen of
> the
> >>> buffer and it was about 320K, and I got only around: ~ 8KB
> >> If it's more than PIPE_BUF, it won't be atomic and can be interleaved
> >> with other entries. Are you sure it's truncated and not just spread
> >> out?
>
Re: ap_log_rerror limit size
I traced this into the Apache source code (ver 2.4.4). It looks like the
error message string is really limited by the size of 8KB.
This line is in server/log.c:1097
"
static void log_error_core(const char *file, int line, int module_index,
int level,
apr_status_t status, const server_rec *s,
const conn_rec *c,
const request_rec *r, apr_pool_t *pool,
const char *fmt, va_list args)
{
char errstr[MAX_STRING_LEN];
"
"
And MAX_STRING_LEN is defined in include/httpd.h:298
/** The default string length */
#define MAX_STRING_LEN HUGE_STRING_LEN
/** The length of a Huge string */
#define HUGE_STRING_LEN 8192
"
I tried to increase this value, recompile, and apparently I got a longer
message.
Please correct me if I am wrong... If this is true then can anyone tell
me why this "HUGE_STRING_LEN" value is a hard-coded value but not a
configurable option ?
Cheers, Vu
On 03/13/2013 11:16 AM, Eric Covener wrote:
On Wed, Mar 13, 2013 at 6:01 AM, Hoang Vu Dang wrote:
Hi guys,
Is there any limit of the size of a message log entry? How to control this ?
I did this:
ap_log_rerror(APLOG_MARK, APLOG_INFO, 0, f->r,
"%s", buffer);
And the buffer was truncated on the error log. I check the strlen of the buffer
and it was about 320K, and I got only around: ~ 8KB
If it's more than PIPE_BUF, it won't be atomic and can be interleaved
with other entries. Are you sure it's truncated and not just spread
out?
Re: ap_log_rerror limit size
Yes I am sure I can't find other entries related to that request. How to find whether I used PIPE_BUF and how to increase that BUF size ? On Mar 13, 2013, at 11:16 AM, Eric Covener wrote: > On Wed, Mar 13, 2013 at 6:01 AM, Hoang Vu Dang wrote: >> Hi guys, >> >> Is there any limit of the size of a message log entry? How to control this ? >> >> I did this: >> >> ap_log_rerror(APLOG_MARK, APLOG_INFO, 0, f->r, >>"%s", buffer); >> >> And the buffer was truncated on the error log. I check the strlen of the >> buffer and it was about 320K, and I got only around: ~ 8KB > > If it's more than PIPE_BUF, it won't be atomic and can be interleaved > with other entries. Are you sure it's truncated and not just spread > out?
ap_log_rerror limit size
Hi guys, Is there any limit of the size of a message log entry? How to control this ? I did this: ap_log_rerror(APLOG_MARK, APLOG_INFO, 0, f->r, "%s", buffer); And the buffer was truncated on the error log. I check the strlen of the buffer and it was about 320K, and I got only around: ~ 8KB Thank, Vu
Re: How to control block size of input_filter data
Thank you for the quick reply ! The context is what I am looking into right now, and It is indeed a right solution to my original question. I just want to know a little bit more detail if you do not mind, you said: "I typically destroy it by placing a callback in the cleanup hook of the req->pool. " What exactly is the callback function that I need to look for ? When it executes, can we be sure that all the data has been processed, and our ctx will be maintained at that state ? Best, Vu On 03/12/2013 10:36 AM, Sorin Manolache wrote: On 2013-03-12 10:16, Hoang-Vu Dang wrote: Hi all, When I write an input_filter, I notice that the data sent from client is not always available in one chunk if it's large. In other words, The input_filter() function will be called multiple times per request. My question is how to have a control on this (for example the size of the chunk until it breaks in to two) ? what should we look into in order to check if the two filters are called from the same request. You can keep the state from one filter invokation to the other in f->ctx, the filter's context. There are many ways to do this. One way I've seen is to check if f->ctx is NULL (if it was NULL then it would mean that it is the first invokation of the filter). If it's NULL, we build the context. Subsequent invokations have the context != NULL. You'll have to destroy the context at the end of the request. I typically destroy it by placing a callback in the cleanup hook of the req->pool. Another way to destroy it, but in my opinion a wrong way, is to destroy it when you encounter EOS in the data processed by the filter. I'd say it's wrong because a wrongly written filter could send data _after_ an EOS bucket and then you could not distinguish between a new request and a request sending data after EOS. Another way to initialize the context is by placing a filter init function when you declare the filter and to initialize the context in this function. This is more elegant in my opinion, because the context is already initialized when the filter is called the first time. The filter context could be any structure, so you can track the filter processing state in it. Regards, Sorin
How to control block size of input_filter data
Hi all, When I write an input_filter, I notice that the data sent from client is not always available in one chunk if it's large. In other words, The input_filter() function will be called multiple times per request. My question is how to have a control on this (for example the size of the chunk until it breaks in to two) ? what should we look into in order to check if the two filters are called from the same request. Thanks, Vu
Re: Removing bogus release from mod_ldap_userdir module?
I second that... I also duplicate my release on mod_dumpost.. but can't find a way to delete it. Vu On 02/03/2013 10:33 AM, Helmut Tessarek wrote: On 03.02.13 4:20 , Daniel Gruno wrote: On 02/03/2013 01:33 AM, John Morrissey wrote: I accidentally created a release for mod_ldap_userdir with no version number; would you remove it, please? It'd be nice if the new site would prevent that. john Done, and yes, that will be on my todo-list for today :) It would also be nice to be able to edit and delete a release as a module owner. Cheers, Helmut
Re: How to write apache module in C through which to retrieve POST form data from browser?
You can take a look at a small module I wrote for myself https://github.com/danghvu/mod_dumpost p/s: I did submit it for review but apparently this list is not so active. On Jan 5, 2013, at 7:13 PM, Dhiren123 wrote: > I am already written a apache module in c and parsed GET data from browser > through "r->args" .But donot know how i retrieve the POST form data ,Anybody > suggest me.. > > > > -- > View this message in context: > http://apache-http-server.18135.n6.nabble.com/How-to-write-apache-module-in-C-through-which-to-retrieve-POST-form-data-from-browser-tp5002469.html > Sent from the Apache HTTP Server - Module Writers mailing list archive at > Nabble.com.
