Re: Proposed Lua backport for 2.4
On 03/13/2013 02:50 AM, Gregg Smith wrote: Hi Daniel, I'm seeing segfaults on that dreadful Windows OS when using LuaMapHandler LuaRoot together. Not to worry, I'm seeing seeing this on trunk as well, so it's not your backport per se. Some likely useless info: http://people.apache.org/~gsmith/httpd/segfault/mod_lua_map_handler_call_stack.txt Cheers, Gregg The backtrace was actually quite helpful :) It would appear that the bug (perhaps) pre-dates my work on mod_lua (or it could be something I've missed completely, who knows). I can see that vm_construct is creating, or attempting to create, a lua VM which returns a null pointer meaning that part failed, but it doesn't check whether the VM is null, making munge_path segfault. At the same time, the lifecycle_pool being passed is also NULL, which makes even less sense to me, since you can see in the backtrace that it wasn't null when it got passed to ap_lua_get_lua_state. Can you tell me which exact lua directives you used for this? which LuaScope, LuaCodeCache and so on? With regards, Daniel.
Re: mod_cache with Cache-Control no-cache= or private=
Here is the patch that strips the no-cache= or private= specified
headers after the origin server's validation, leaving the only headers
updated by the origin.
Regards,
Yann.
Index: modules/cache/cache_storage.c
===
--- modules/cache/cache_storage.c (revision 1456050)
+++ modules/cache/cache_storage.c (working copy)
@@ -156,6 +156,51 @@
apr_table_unset(h-resp_hdrs, Last-Modified);
}
+v = apr_table_get(h-resp_hdrs, Cache-Control);
+if (v (h-cache_obj-info.control.no_cache_header ||
+ h-cache_obj-info.control.private_header)) {
+/*
+ * RFC2616 14.9.1: If the no-cache directive does specify one or more
+ * field-names, then a cache MAY use the response to satisfy a
+ * subsequent request, subject to any other restrictions on caching.
+ * However, the specified field-name(s) MUST NOT be sent in the
+ * response to a subsequent request without successful revalidation
+ * with the origin server.
+ *
+ * Hence we will strip these cached headers (if any) and let the only
+ * ones validated by the origin server.
+ */
+char *token;
+apr_size_t len;
+while ((token = ap_get_list_item(r-pool, v))) {
+/* ap_get_list_item() strips the spurious whitespaces and
+ * lowercases anything (but the quoted-strings) */
+if (strncmp(token, no-cache=, 9) == 0) {
+token += 9;
+}
+else if (strncmp(token, private=, 8) == 0) {
+token += 8;
+}
+else {
+continue;
+}
+
+/* RFC2616 14.9: quoted list of field-names */
+len = strlen(token);
+if (token[0] == '' token[--len] == '') {
+(++token)[--len] = '\0';
+do {
+const char *name = ap_cache_tokstr(r-pool, token,
+ (const char**)token);
+if (name) {
+/* strip that name header the response */
+apr_table_unset(h-resp_hdrs, name);
+}
+} while (token);
+}
+}
+}
+
/* The HTTP specification says that it is legal to merge duplicate
* headers into one. Some browsers that support Cookies don't like
* merged headers and prefer that each Set-Cookie header is sent
Re: mod_cache with Cache-Control no-cache= or private=
On 11 Mar 2013, at 12:50 PM, Yann Ylavic ylavic@gmail.com wrote: The way I read the spec, the specified field-name(s) MUST NOT be sent in the response to a subsequent request without successful revalidation with the origin server. What this means is that if the specified field names are found to be present in the cached response, then the origin server needs to be given the opportunity to update these fields through a conditional request. In the current cache code, we return 0 meaning this is stale, revalidate, and a conditional request is sent to the origin. We hope the origin sends 304 Not Modified, with updated headers corresponding to the fields. Ok, I see your point, and this is surely the right reading of the rfc, but there is necessarily a difference between no-cache and no-cache=header(s), particularly with the handling of that (stale) header(s). For what I understand now, if the origin does not send (one of) the header(s) in its 304 response, the stale header(s) MUST NOT be served. I don't read it that way from the spec, I think it all comes down to the phrase without successful revalidation with the origin server. I read it as without successful revalidation [of the whole request] with the origin server. In other words, the origin server sent the original header, if the origin server doesn't update the header in the 304 response then it means I've had my opportunity to revalidate the entity, current cached value is fine, send it. Roy ultimately would be able to answer this? Regards, Graham -- smime.p7s Description: S/MIME cryptographic signature
Re: mod_cache with Cache-Control no-cache= or private=
On Wed, Mar 13, 2013 at 6:20 PM, Graham Leggett minf...@sharp.fm wrote: On 11 Mar 2013, at 12:50 PM, Yann Ylavic ylavic@gmail.com wrote: The way I read the spec, the specified field-name(s) MUST NOT be sent in the response to a subsequent request without successful revalidation with the origin server. What this means is that if the specified field names are found to be present in the cached response, then the origin server needs to be given the opportunity to update these fields through a conditional request. In the current cache code, we return 0 meaning this is stale, revalidate, and a conditional request is sent to the origin. We hope the origin sends 304 Not Modified, with updated headers corresponding to the fields. Ok, I see your point, and this is surely the right reading of the rfc, but there is necessarily a difference between no-cache and no-cache=header(s), particularly with the handling of that (stale) header(s). For what I understand now, if the origin does not send (one of) the header(s) in its 304 response, the stale header(s) MUST NOT be served. I don't read it that way from the spec, I think it all comes down to the phrase without successful revalidation with the origin server. I read it as without successful revalidation [of the whole request] with the origin server. In other words, the origin server sent the original header, if the origin server doesn't update the header in the 304 response then it means I've had my opportunity to revalidate the entity, current cached value is fine, send it. How would the origin invalidate a Set-Cookie, with an empty one ? Regards, Yann.
Re: mod_cache with Cache-Control no-cache= or private=
On 13 Mar 2013, at 7:27 PM, Yann Ylavic ylavic@gmail.com wrote: How would the origin invalidate a Set-Cookie, with an empty one ? I would imagine with a 200 OK. Roy would be able to confirm. Regards, Graham -- smime.p7s Description: S/MIME cryptographic signature
Re: mod_cache with Cache-Control no-cache= or private=
On Wed, Mar 13, 2013 at 5:27 PM, Yann Ylavic ylavic@gmail.com wrote: How would the origin invalidate a Set-Cookie, with an empty one ? Regards, Yann. Set it again, with an in the past expiry date. Cheers Tom
Re: mod_cache with Cache-Control no-cache= or private=
On Wed, Mar 13, 2013 at 6:30 PM, Graham Leggett minf...@sharp.fm wrote: On 13 Mar 2013, at 7:27 PM, Yann Ylavic ylavic@gmail.com wrote: How would the origin invalidate a Set-Cookie, with an empty one ? I would imagine with a 200 OK. Roy would be able to confirm. Well, I can't see the difference with the no-cache without a header specified (the actual code) then... Regards, Yann.
Re: mod_cache with Cache-Control no-cache= or private=
On Wed, Mar 13, 2013 at 6:35 PM, Tom Evans tevans...@googlemail.com wrote: On Wed, Mar 13, 2013 at 5:27 PM, Yann Ylavic ylavic@gmail.com wrote: How would the origin invalidate a Set-Cookie, with an empty one ? Regards, Yann. Set it again, with an in the past expiry date. Well, that's not exactly the same thing, the user may have a valid Cookie (which is not the one cached) the origin wants to keep going on. I meant invalidating the cached cookie, not the one of the user. Cheers, Yann.
Re: Proposed Lua backport for 2.4
On 3/13/2013 4:44 AM, Daniel Gruno wrote: On 03/13/2013 02:50 AM, Gregg Smith wrote: Hi Daniel, I'm seeing segfaults on that dreadful Windows OS when using LuaMapHandler LuaRoot together. The backtrace was actually quite helpful :) It would appear that the bug (perhaps) pre-dates my work on mod_lua (or it could be something I've missed completely, who knows). I can see that vm_construct is creating, or attempting to create, a lua VM which returns a null pointer meaning that part failed, but it doesn't check whether the VM is null, making munge_path segfault. At the same time, the lifecycle_pool being passed is also NULL, which makes even less sense to me, since you can see in the backtrace that it wasn't null when it got passed to ap_lua_get_lua_state. Can you tell me which exact lua directives you used for this? which LuaScope, LuaCodeCache and so on? IfModule lua_module AddHandler lua-script .lua LuaMapHandler /testlua /usr/etc/lua/example.lua LuaRoot /usr/etc/lua Directory /usr/etc/lua Options All AllowOverride None Require all granted /Directory /IfModule So since not specifically configured, the defaults of once and stat respectively. Regards, Gregg
Re: Proposed Lua backport for 2.4
On 03/13/2013 08:39 PM, Gregg Smith wrote: On 3/13/2013 4:44 AM, Daniel Gruno wrote: On 03/13/2013 02:50 AM, Gregg Smith wrote: Hi Daniel, I'm seeing segfaults on that dreadful Windows OS when using LuaMapHandler LuaRoot together. The backtrace was actually quite helpful :) It would appear that the bug (perhaps) pre-dates my work on mod_lua (or it could be something I've missed completely, who knows). I can see that vm_construct is creating, or attempting to create, a lua VM which returns a null pointer meaning that part failed, but it doesn't check whether the VM is null, making munge_path segfault. At the same time, the lifecycle_pool being passed is also NULL, which makes even less sense to me, since you can see in the backtrace that it wasn't null when it got passed to ap_lua_get_lua_state. Can you tell me which exact lua directives you used for this? which LuaScope, LuaCodeCache and so on? IfModule lua_module AddHandler lua-script .lua LuaMapHandler /testlua /usr/etc/lua/example.lua LuaRoot /usr/etc/lua Directory /usr/etc/lua Options All AllowOverride None Require all granted /Directory /IfModule So since not specifically configured, the defaults of once and stat respectively. Regards, Gregg I am unable to get my own server to segfault, and I can't seem to find anything in the code that would cause the pool to suddenly become null. Your backtrace seems to indicate that your request calls: ap_lua_get_lua_state(apr_pool_t * lifecycle_pool=0x0258c0e8, ap_lua_vm_spec * spec=0x0258b658, request_rec * r=0x0258a120) which then calls: vm_construct(lua_State * * vm=0x036efdc0, void * params=0x0258b658, apr_pool_t * lifecycle_pool=0x) except lifecycle_pool never gets changed anywhere in the code, it's just passed straight through to vm_construct...so whatever made it turn into 0x0 is beyond my eyes to spot. If anyone else can spot something I'm missing, please do speak up, otherwise I'll probably chalk this one down to a Windows oddity. With regards, Daniel.
Re: mod_cache with Cache-Control no-cache= or private=
On 13 Mar 2013, at 17:41, Yann Ylavic ylavic@gmail.com wrote: On Wed, Mar 13, 2013 at 6:35 PM, Tom Evans tevans...@googlemail.com wrote: On Wed, Mar 13, 2013 at 5:27 PM, Yann Ylavic ylavic@gmail.com wrote: How would the origin invalidate a Set-Cookie, with an empty one ? Regards, Yann. Set it again, with an in the past expiry date. Well, that's not exactly the same thing, the user may have a valid Cookie (which is not the one cached) the origin wants to keep going on. I meant invalidating the cached cookie, not the one of the user. Is this the situation you're worried about: ClientA: GET /foo HTTP/1.1 ClientA: Host: … ReverseProxy: GET /foo HTTP/1.1 ReverseProxy: Host: … Origin: HTTP/1.1 200 OK Origin: Date: … Origin: Set-Cookie: data=AA Origin: Cache-Control: private=Set-Cookie ReverseProxy: HTTP/1.1 200 OK ReverseProxy: Date: … ReverseProxy: Set-Cookie: data=AA ReverseProxy: Cache-Control: private=Set-Cookie ClientB: GET /foo HTTP/1.1 ClientB: Host: … ClientB: Cookie: data=BB ReverseProxy: GET /foo HTTP/1.1 ReverseProxy: Host: … ReverseProxy: Cookie: data=BBB Origin: HTTP/1.1 304 Not Modified Origin: Date: … Origin: Cache-Control: private=Set-Cookie This should just work. The final reply from the cacheing reverse proxy should look like this: ReverseProxy: HTTP/1.1 304 Not Modified ReverseProxy: Date: … and the Set-Cookie: header from the stored request would not be used (in fact, the proxy may have elected not to store it). The origin doesn't have to mention that header in the 304 response. -- Tim Bannister – is...@jellybaby.net
Re: svn commit: r1451478 - /httpd/httpd/trunk/server/util_script.c
Note that there is some macro magic in http_log.h that does this
automatically on C99 compilers. There is nothing wrong with doing the
check explicitly, and it is definitely a good idea if the saved function
call is very expensive. But in general other improvements may have more
impact and therefore be a better use of your time. But of course that's
your choice ;)
On Fri, 1 Mar 2013, jaillet...@apache.org wrote:
Author: jailletc36
Date: Fri Mar 1 06:33:40 2013
New Revision: 1451478
URL: http://svn.apache.org/r1451478
Log:
Avoid some memory allocation on error path in 'http2env' if TRACE1 logging is
not activated
Avoid a function ca
Modified:
httpd/httpd/trunk/server/util_script.c
Modified: httpd/httpd/trunk/server/util_script.c
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/server/util_script.c?rev=1451478r1=1451477r2=1451478view=diff
==
--- httpd/httpd/trunk/server/util_script.c (original)
+++ httpd/httpd/trunk/server/util_script.c Fri Mar 1 06:33:40 2013
@@ -73,9 +73,10 @@ static char *http2env(request_rec *r, co
*cp++ = '_';
}
else {
-ap_log_rerror(APLOG_MARK, APLOG_TRACE1, 0, r,
- Not exporting header with invalid name as envvar:
%s,
- ap_escape_logitem(r-pool, w));
+if (APLOGrtrace1(r))
+ap_log_rerror(APLOG_MARK, APLOG_TRACE1, 0, r,
+Not exporting header with invalid name as envvar:
%s,
+ap_escape_logitem(r-pool, w));
return NULL;
}
}
@@ -594,9 +595,10 @@ AP_DECLARE(int) ap_scan_script_header_er
Invalid status line from script '%s': %.30s,
apr_filepath_name_get(r-filename), l);
else
-ap_log_rerror(SCRIPT_LOG_MARK, APLOG_TRACE1, 0, r,
- Status line from script '%s': %.30s,
- apr_filepath_name_get(r-filename), l);
+if (APLOGrtrace1(r))
+ ap_log_rerror(SCRIPT_LOG_MARK, APLOG_TRACE1, 0, r,
+ Status line from script '%s': %.30s,
+ apr_filepath_name_get(r-filename), l);
r-status_line = apr_pstrdup(r-pool, l);
}
else if (!strcasecmp(w, Location)) {
Re: mod_cache with Cache-Control no-cache= or private=
On Wed, Mar 13, 2013 at 9:28 PM, Tim Bannister is...@jellybaby.net wrote: Is this the situation you're worried about: ClientA: GET /foo HTTP/1.1 ReverseProxy: GET /foo HTTP/1.1 Origin: HTTP/1.1 200 OK Origin: Set-Cookie: data=AA Origin: Cache-Control: private=Set-Cookie ReverseProxy: Set-Cookie: data=AA ReverseProxy: Cache-Control: private=Set-Cookie ClientB: GET /foo HTTP/1.1 ClientB: Cookie: data=BB ReverseProxy: GET /foo HTTP/1.1 ReverseProxy: Cookie: data=BBB Origin: HTTP/1.1 304 Not Modified Yes, about what happens now, the ReverseProxy (mod_cache) must not Set-Cookie: data=AA to ClientB. This should just work. The final reply from the cacheing reverse proxy should look like this: ReverseProxy: HTTP/1.1 304 Not Modified ReverseProxy: Date: … This actually does not work, mod_cache will serve the cached Set-Cookie. The CacheIgnoreHeaders directive only can prevent this (not controlled by the origin). The final reply to ClientB, whose request is not conditional, can also be : ReverseProxy: HTTP/1.1 200 OK ReverseProxy: Cache-Control: private=Set-Cookie ReverseProxy: cached body That's the main goal I guess (limit backend hits for large things). and the Set-Cookie: header from the stored request would not be used (in fact, the proxy may have elected not to store it). The origin doesn't have to mention that header in the 304 response. In mod_cache the no-store of a particular header is harder to patch than the no-cache (ie. do not serve without revalidation), but indeed the former would be more efficient, no need to sanitize each served response. For the private=, the rfc does not say more than its BNF... If private has the same semantic as without the =, the header should not be stored (the Cache-Control: private response is not stored by mod_cache). In all cases, IMHO, no cached Set-Cookie should aver played by a cache with private/no-cache=Set-Cookie associated with the resource.
Re: svn commit: r1451478 - /httpd/httpd/trunk/server/util_script.c
My goal was to check for useless memory allocation when calling logging
function.
Logging with TRACE is unlikely to output something on a production
machine. However, function called as parameters of the logging function
will still be called.
I made a check on the whole source code to check for useless memory
allocation as a side effect of logging.
I found the one below, in an error path.
It is part of the time I'm spending to analyze memory allocation and use
done by httpd.
I've modified apr_palloc and so on to give me some feedback and I'm
looking at it.
With current trunk, with a light configuration and a server configured
to be single threaded, 11541 calls to apr_palloc, for a total of 4,4 Mo,
are performed during stat-up. According to my configuration, I find it
high, but ok, why not, it is just start-up
For processing a single request like http://localhosr/foo, 254 new calls
are done for a total of 15 ko, mostly in the request pool.
Reducing it to fit in only one 8k, if possible, would be nice. It would
avoid the pool to allocate more memory.
Here is my goal.
BTW, I tried to activate pool debug with using |-enable-pool-debug=all
but the server crashes while starting on my test machine.
Do you know if it is supposed to work (and I do something wrong) or no
one uses it with httpd ?
I haven't saved details about it but it would be easy to reproduce if
you are interested.
|CJ
Le 13/03/2013 22:26, Stefan Fritsch a écrit :
Note that there is some macro magic in http_log.h that does this
automatically on C99 compilers. There is nothing wrong with doing the
check explicitly, and it is definitely a good idea if the saved
function call is very expensive. But in general other improvements may
have more impact and therefore be a better use of your time. But of
course that's your choice ;)
On Fri, 1 Mar 2013, jaillet...@apache.org wrote:
Author: jailletc36
Date: Fri Mar 1 06:33:40 2013
New Revision: 1451478
URL: http://svn.apache.org/r1451478
Log:
Avoid some memory allocation on error path in 'http2env' if TRACE1
logging is not activated
Avoid a function ca
Modified:
httpd/httpd/trunk/server/util_script.c
Modified: httpd/httpd/trunk/server/util_script.c
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/server/util_script.c?rev=1451478r1=1451477r2=1451478view=diff
==
--- httpd/httpd/trunk/server/util_script.c (original)
+++ httpd/httpd/trunk/server/util_script.c Fri Mar 1 06:33:40 2013
@@ -73,9 +73,10 @@ static char *http2env(request_rec *r, co
*cp++ = '_';
}
else {
-ap_log_rerror(APLOG_MARK, APLOG_TRACE1, 0, r,
- Not exporting header with invalid name as
envvar: %s,
- ap_escape_logitem(r-pool, w));
+if (APLOGrtrace1(r))
+ap_log_rerror(APLOG_MARK, APLOG_TRACE1, 0, r,
+Not exporting header with invalid name
as envvar: %s,
+ap_escape_logitem(r-pool, w));
return NULL;
}
}
Re: some key fields of request_rec are null
On Tue, Mar 12, 2013 at 8:04 PM, Nce Rt nce...@yahoo.com wrote: here is one of the past emails: On Wed, Mar 6, 2013 at 4:21 PM, Nce Rt nce...@yahoo.com wrote: A custom handler which is registered to run APR_HOOK_FIRST has these fields null when processing http request: r-content_type, r-parsed_uri.scheme instead of being a moronic moaner, make some common-sensical assumptions if you really know what you're talking about. There are many different handler phases, all of which you can set your module to APR_HOOK_FIRST into. You haven't said if this is a content handler, a fixup handler, etc. If you hook in to post_read_request, then duh, most of the fields on request_rec are not populated. But you know all that already, I'm just a moronic moaner, so I'll leave you to your anger. I'm sure insulting people will eventually lead you to the correct method.
Re: ap_log_rerror limit size
On Wed, Mar 13, 2013 at 6:16 AM, Eric Covener cove...@gmail.com wrote: On Wed, Mar 13, 2013 at 6:01 AM, Hoang Vu Dang dang@gmail.com 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? Er if using a piped logger that is.
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 cove...@gmail.com wrote: On Wed, Mar 13, 2013 at 6:01 AM, Hoang Vu Dang dang@gmail.com 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
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 dang@gmail.com 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
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, r...@seid-online.de 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 dang@gmail.com
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?
