DO NOT REPLY [Bug 32915] - (snapshot 2.0.0.2002) Stopping apache causes error on stop
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32915. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32915 --- Additional Comments From [EMAIL PROTECTED] 2005-01-04 07:17 --- My mistake, the local httpd-2.0 module on my box included an httpd-2.1 patch. The corrected Apache 2.0 - compatible build is now available for testing and validation at; http://httpd.apache.org/dev/dist/mod_aspdotnet-2.0.0.2002-snapshot-rev124071.msi -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 32658] - mod_aspdotnet returns stale cached files
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32658. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32658 --- Additional Comments From [EMAIL PROTECTED] 2005-01-04 07:17 --- My mistake, the local httpd-2.0 module on my box included an httpd-2.1 patch. The corrected Apache 2.0 - compatible build is now available for testing and validation at; http://httpd.apache.org/dev/dist/mod_aspdotnet-2.0.0.2002-snapshot-rev124071.msi -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 32902] - Lowercase request headers not recognized by mod_aspdotnet apps.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32902. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32902 --- Additional Comments From [EMAIL PROTECTED] 2005-01-04 18:41 --- Hehe, I've download the msi package... But this time I can't even install it LOL ;-)... I've got a wonderfull error like: Internal Error 2765. Apache.Web (It appears when the installer start) PS: ScreenShot: http://binaire.dynu.com/msi_error.jpg Have a nice day ;-) oLiViEr -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: C-L or T-E: chunked for proxied request bodies
On Sun, 2 Jan 2005 15:28:54 -0500, Jeff Trawick [EMAIL PROTECTED] wrote:
On Sun, 2 Jan 2005 11:31:36 -0800 (PST), Justin Erenkrantz
[EMAIL PROTECTED] wrote:
Turning on sendchunks by default is going to result in broken behavior on
all sorts of popular sites:
I believe you, though there are plenty of chunks-are-beautiful
scenarios as well. Also, there is a limit to regression since new
logic can preserve the existing C-L and stream the request body when
there is no input filter.
I don't mind greatly changing the pseudo-code I mentioned earlier to
default to spooling the request body in order to compute the C-L. The
bulk of the logic should be able to handle either preference. But I
will add some logic to check if the client sent us chunks, in which
case we'll send the origin server chunks as well. (I really want to
avoid the spooling if at all possible.)
FWIW, it seems likely that I'll have a barely tested patch in the next 24
hours.
Here is current patch-in-progress. I'd guess there many bugs. I
don't mean to waste anyone's time with an in-progress mess, but any
comments on the current state would be very valuable.
Thanks!
Index: modules/proxy/proxy_http.c
===
--- modules/proxy/proxy_http.c (revision 123727)
+++ modules/proxy/proxy_http.c (working copy)
@@ -235,6 +235,443 @@
apr_table_unset(headers, Connection);
}
+static void add_te_chunked(apr_pool_t *p,
+ apr_bucket_alloc_t *bucket_alloc,
+ apr_bucket_brigade *header_brigade)
+{
+apr_bucket *e;
+char *buf;
+const char te_hdr[] = Transfer-Encoding: chunked CRLF;
+
+buf = apr_pmemdup(p, te_hdr, sizeof(te_hdr)-1);
+ap_xlate_proto_to_ascii(buf, sizeof(te_hdr)-1);
+
+e = apr_bucket_pool_create(buf, sizeof(te_hdr)-1, p, bucket_alloc);
+APR_BRIGADE_INSERT_TAIL(header_brigade, e);
+}
+
+static void add_cl(apr_pool_t *p,
+ apr_bucket_alloc_t *bucket_alloc,
+ apr_bucket_brigade *header_brigade,
+ const char *cl_val)
+{
+apr_bucket *e;
+char *buf;
+
+buf = apr_pstrcat(p, Content-Length: ,
+ cl_val,
+ CRLF,
+ NULL);
+ap_xlate_proto_to_ascii(buf, strlen(buf));
+e = apr_bucket_pool_create(buf, strlen(buf), p, bucket_alloc);
+APR_BRIGADE_INSERT_TAIL(header_brigade, e);
+}
+
+#define ASCII_CRLF \015\012
+#define ASCII_ZERO \060
+
+static void terminate_headers(apr_bucket_alloc_t *bucket_alloc,
+ apr_bucket_brigade *header_brigade)
+{
+apr_bucket *e;
+
+/* add empty line at the end of the headers */
+e = apr_bucket_immortal_create(ASCII_CRLF, 2, bucket_alloc);
+APR_BRIGADE_INSERT_TAIL(header_brigade, e);
+}
+
+static apr_status_t pass_brigade(request_rec *r, proxy_conn_rec *conn,
+ conn_rec *origin, apr_bucket_brigade *b,
+ int flush)
+{
+apr_status_t status;
+apr_off_t transferred;
+
+if (flush) {
+apr_bucket *e = apr_bucket_flush_create(r-connection-bucket_alloc);
+APR_BRIGADE_INSERT_TAIL(b, e);
+}
+apr_brigade_length(b, 0, transferred);
+if (transferred != -1)
+conn-worker-s-transferred += transferred;
+status = ap_pass_brigade(origin-output_filters, b);
+if (status != APR_SUCCESS) {
+ap_log_error(APLOG_MARK, APLOG_ERR, status, r-server,
+ proxy: pass request data failed to %pI (%s),
+ conn-addr, conn-hostname);
+return status;
+}
+apr_brigade_cleanup(b);
+return APR_SUCCESS;
+}
+
+static apr_status_t stream_reqbody_chunked(apr_pool_t *p,
+ request_rec *r,
+ proxy_conn_rec *conn,
+ conn_rec *origin,
+ apr_bucket_brigade *header_brigade)
+{
+int seen_eos = 0;
+apr_size_t hdr_len;
+apr_off_t bytes;
+apr_status_t status;
+apr_bucket_brigade *b, *input_brigade;
+apr_bucket *e;
+
+input_brigade = apr_brigade_create(p, origin-bucket_alloc);
+
+do {
+char chunk_hdr[20]; /* must be here due to transient bucket. */
+
+status = ap_get_brigade(r-input_filters, input_brigade,
+AP_MODE_READBYTES, APR_BLOCK_READ,
+HUGE_STRING_LEN);
+
+if (status != APR_SUCCESS) {
+return status;
+}
+
+/* If this brigade contain EOS, either stop or remove it. */
+if (APR_BUCKET_IS_EOS(APR_BRIGADE_LAST(input_brigade))) {
+seen_eos = 1;
+
+/* We can't pass this EOS to the output_filters. */
+e = APR_BRIGADE_LAST(input_brigade);
+apr_bucket_delete(e);
+
+/* As a
Re: svn commit: r124080 - /httpd/httpd/trunk/modules/cache/mod_disk_cache.c
On 4 Jan 2005 09:58:09 -, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: jfclere Date: Tue Jan 4 01:58:01 2005 New Revision: 124080 URL: http://svn.apache.org/viewcvs?view=revrev=124080 Log: Add including of util_charset.h otherwise ap_hdrs_from_ascii is not defined. Modified: httpd/httpd/trunk/modules/cache/mod_disk_cache.c Modified: httpd/httpd/trunk/modules/cache/mod_disk_cache.c Url: http://svn.apache.org/viewcvs/httpd/httpd/trunk/modules/cache/mod_disk_cache.c?view=diffrev=124080p1=httpd/httpd/trunk/modules/cache/mod_disk_cache.cr1=124079p2=httpd/httpd/trunk/modules/cache/mod_disk_cache.cr2=124080 == --- httpd/httpd/trunk/modules/cache/mod_disk_cache.c(original) +++ httpd/httpd/trunk/modules/cache/mod_disk_cache.cTue Jan 4 01:58:01 2005 @@ -20,6 +20,10 @@ #include util_filter.h #include util_script.h +#if APR_CHARSET_EBCDIC +#include util_charset.h +#endif why not include it unconditionally?
Re: C-L or T-E: chunked for proxied request bodies
--On Tuesday, January 4, 2005 8:48 AM -0500 Jeff Trawick [EMAIL PROTECTED] wrote: Here is current patch-in-progress. I'd guess there many bugs. I don't mean to waste anyone's time with an in-progress mess, but any comments on the current state would be very valuable. How about creating a branch in Subversion? You can check in the patch there so that we can review it and make improvements to it there. I think we're mostly in agreement that we'll change our current behavior. I've always disliked patch iterations on a mailing list: we have a cool version control system with cheap branches. Let's use it! =) -- justin
Re: C-L or T-E: chunked for proxied request bodies
On Tue, 04 Jan 2005 09:45:13 -0800, Justin Erenkrantz [EMAIL PROTECTED] wrote: --On Tuesday, January 4, 2005 8:48 AM -0500 Jeff Trawick [EMAIL PROTECTED] wrote: Here is current patch-in-progress. I'd guess there many bugs. I don't mean to waste anyone's time with an in-progress mess, but any comments on the current state would be very valuable. How about creating a branch in Subversion? You can check in the patch there so that we can review it and make improvements to it there. I think we're mostly in agreement that we'll change our current behavior. does this look correct? svn copy https://svn.apache.org/repos/asf/httpd/httpd/trunk \ https://svn.apache.org/repos/asf/httpd/httpd/branches/proxy-reqbody
Auth LDAP ssl/tls differences
It seems that our support for ssl/tls with mod_ldap is considerably confusing and frustrating for users. The recent interest in fixing support for the Solaris/Netscape/Mozilla library reminded me of the fact that we need to finish thinking this through. Fast summary for those less familiar; there are two SSL schemas for LDAP communications. . Solaris/Netscape/Mozilla support is based on explicit SSLv3 connection to the ldaps:// port, 636. . OpenLDAP supports ldaps://, it also supports STARTTLS protocol over port 389. STARTTLS should not be invoked by the scheme ldaps:// (it's a semantic error - ldaps:// should not refer to an upgraded SSL connection, and would imply port 636 which is not correct for this protocol.) The correct scheme/port for STARTTLS LDAP connections is ldap:// with port 389 implicit. We need a mechanism to clarify to mod_ldap that TLS security is desired. Incident http://issues.apache.org/bugzilla/show_bug.cgi?id=31443 offers a solution which we should consider adopting. As I was asking for some offline feedback - Graham mentioned that some implementations use the URL to specify that STARTTLS is desired. But without some references the proposal seems to be a better option - we shouldn't be redefining the ldap:// URI space. Does anyone have any references to specifying STARTTLS as part of the URI to the ldap server? Any other comments on this patch before I integrate into httpd-2.1? Bill
Re: Auth LDAP ssl/tls differences
On Jan 4, 2005, at 2:40 PM, William A. Rowe, Jr. wrote: Incident http://issues.apache.org/bugzilla/show_bug.cgi?id=31443 offers a solution which we should consider adopting. As I was asking for some offline feedback - Graham mentioned that some implementations use the URL to specify that STARTTLS is desired. But without some references the proposal seems to be a better option - we shouldn't be redefining the ldap:// URI space. Does anyone have any references to specifying STARTTLS as part of the URI to the ldap server? Any other comments on this patch before I integrate into httpd-2.1? +1 for adding it in... Even better if it's made into a branch for development before folding back into HEAD (yeah svn!) but no matter what, let's fold it in an start cracking on it.
Re: Bug with __stdcall modules on Windows
At 06:06 PM 1/4/2005, Andre Pang wrote: [...] This doesn't quite work however, because foo_handler is declared to be of the ap_HOOK_handler_t type. Since the ap_HOOK_handler_t typedef is declared in the Apache headers files without __cdecl, the compiler type-checks ap_HOOK_handler_t as __stdcall (because the header files are included by the module, and since the module is compiled with __stdcall, any header declarations are also presumed to be __stdcall). Let me make sure I understand; you build your module forcing the /Gz option? I'll consider the minimal semantics to force this to behave (we have a set of macros, AP[...]_DECLARE_NONSTD) which should actually handle this nicely, with the addition of __cdecl. It's up to you to correctly declare your registered hook entry points as __cdecl if you insist on the nonstandard /Gz compiler option. Bill
Re: Bug with __stdcall modules on Windows
On 05/01/2005, at 1:17 PM, William A. Rowe, Jr. wrote:
At 06:06 PM 1/4/2005, Andre Pang wrote:
[...]
This doesn't quite work however, because foo_handler is declared to be
of the ap_HOOK_handler_t type. Since the ap_HOOK_handler_t typedef is
declared in the Apache headers files without __cdecl, the compiler
type-checks ap_HOOK_handler_t as __stdcall (because the header files
are included by the module, and since the module is compiled with
__stdcall, any header declarations are also presumed to be __stdcall).
Let me make sure I understand; you build your module forcing
the /Gz option?
That's exactly right.
I'll consider the minimal semantics to force this to behave
(we have a set of macros, AP[...]_DECLARE_NONSTD) which should
actually handle this nicely, with the addition of __cdecl.
That sounds perfect to me. I mentioned this in my original message,
too:
* Add an AP_MODULE_ENTRY_POINT macro to declare direct function
entry points into a module, similar to how AP_MODULE_DECLARE_DATA is
needed for module declarations. Or, change the
AP_MODULE_DECLARE_NONSTD macro so that it contains __cdecl on
Windows.
... so it looks like we're in sync there. Adding __cdecl to
AP_MODULE_DECLARE_NONSTD sounds perfect.
It's up to you to correctly declare your registered hook
entry points as __cdecl if you insist on the nonstandard /Gz
compiler option.
I do correctly declare my hook entry points as __cdecl, but this isn't
quite enough.
The problem is that when the Apache header files are #included by the
module's source code, the ap_HOOK_handler_t and module typedefs expect
__stdcall function pointers (because I'm compiling with /Gz).
Specifically, I mean these parameters:
static void __cdecl foo_register_hooks(apr_pool_t *p)
{
ap_hook_handler(foo_handler /* -- this function pointer
needs to be typedef'ed as
__cdecl */,
NULL, NULL, APR_HOOK_MIDDLE);
}
and
module AP_MODULE_DECLARE_DATA foo_module = {
STANDARD20_MODULE_STUFF,
NULL, /* create per-dirconfig structures */
NULL, /* merge per-dirconfig structures */
NULL, /* create per-server config structures */
NULL, /* merge per-server config structures */
NULL, /* table of config file commands */
foo_register_hooks /* -- this function pointer needs to be
typedef'ed as __cdecl (register hooks)
*/
};
I'd send a patch for the Apache/APR headers myself, but I looked hard
for the typedefs for ap_hook_handler and the function pointer for the
module struct and couldn't find them in any of the .h files, sorry.
I'm hoping you can help me out with that.
--
% Andre Pang : trust.in.love.to.save
Re: Auth LDAP ssl/tls differences
William A. Rowe, Jr. said: Incident http://issues.apache.org/bugzilla/show_bug.cgi?id=31443 offers a solution which we should consider adopting. As I was asking for some offline feedback - Graham mentioned that some implementations use the URL to specify that STARTTLS is desired. But without some references the proposal seems to be a better option - we shouldn't be redefining the ldap:// URI space. Doing some Googling, it seems that an out of url directive seems to be the way everyone else is handling it. Let me look at this patch - it will probably need some reworking to fit in with the binary compatibility requirements of APR, but I need an LDAP enabled release of APR in the next few days, so there is an urgency to finish this off :) Regards, Graham --
