Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm
On 6 Apr 2002 [EMAIL PROTECTED] wrote: dougm 02/04/05 18:39:31 Modified:perl-framework/Apache-Test/lib/Apache TestConfig.pm Log: try MP_AP_PREFIX in modperl build config for httpd location hint Doug. DOOD. You're working too hard. GO PARTY! ;) -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm
On Fri, 5 Apr 2002, Cliff Woolley wrote: Doug. DOOD. You're working too hard. GO PARTY! ;) well, i am drinking a beer at least. wasn't expecting this GA push today, so i'm scrambling to get a modperl release together. then i will party like never before!
2.0.35 related: Website tweak, upgrade apache.org servers
Hi, http://httpd.apache.org still shows: Apache 1.3.24 is the best version of Apache currently available; everyone running 1.2.X servers or earlier are strongly urged to upgrade to 1.3, as there will not be any further 1.2.X releases. At present, the Win32 port of Apache is not as stable as the UNIX version. We probably want to demote 1.3 a bit. And, IMHO, we should upgrade the apache.org servers (at least icarus deserves an upgrade) to 2.0.35. Sander
RE: 2.0.35 related: Website tweak, upgrade apache.org servers
-Original Message- From: Sander Striker [mailto:[EMAIL PROTECTED]] Sent: Saturday, April 06, 2002 1:23 PM http://httpd.apache.org still shows: Apache 1.3.24 is the best version of Apache currently available; everyone running 1.2.X servers or earlier are strongly urged to upgrade to 1.3, as there will not be any further 1.2.X releases. At present, the Win32 port of Apache is not as stable as the UNIX version. We probably want to demote 1.3 a bit. What bothers me is the statement the Win32 port of Apache is not as stable as the UNIX version. Are there any chances to get rid of that (IMO stupid) Win32 port warning stuffs. If the Win32 port is not as stable as the UNIX one, how the stable is UNIX Solaris compared to UNIX AIX, UNIX Linux, etc... And on the other hand what is the Win32 port? Is it Windows 95, Windows NT 4, 2000, or XP? MT.
RE: 2.0.35 related: Website tweak, upgrade apache.org servers
From: Mladen Turk [mailto:[EMAIL PROTECTED]] Sent: 06 April 2002 13:53 http://httpd.apache.org still shows: Apache 1.3.24 is the best version of Apache currently available; everyone running 1.2.X servers or earlier are strongly urged to upgrade to 1.3, as there will not be any further 1.2.X releases. At present, the Win32 port of Apache is not as stable as the UNIX version. We probably want to demote 1.3 a bit. What bothers me is the statement the Win32 port of Apache is not as stable as the UNIX version. This is not in the 2.0 part of the page. This only goes for 1.3. In the 2.0 section: This version of Apache is known to work on many versions of Unix, BeOS, OS/2, Windows, and Netware. Because of many of the advancements in Apache 2.0, the initial release of Apache is expected to perform equally well on all supported platforms Are there any chances to get rid of that (IMO stupid) Win32 port warning stuffs. No need, there is no warning ;) If the Win32 port is not as stable as the UNIX one, how the stable is UNIX Solaris compared to UNIX AIX, UNIX Linux, etc... See above. And on the other hand what is the Win32 port? Is it Windows 95, Windows NT 4, 2000, or XP? I think that we can safely assume that Apache 2.0 was targetted at Windows NT 4 and up. I personally wouldn't want to have to worry about Windows 9x (for obvious reasons I think). MT. Sander
[Patch] Namespace protect and export getline and get_chunk_size
Hi all,
In preparation for a bugfix to proxy and its broken chunking in v1.3, I
need to make getline() and get_chunk_size() available to proxy.
This patch namespace protects and exports these two functions. Will
commit later today if there are no objections...
Regards,
Graham
--
-
[EMAIL PROTECTED]There's a moon
over Bourbon Street
tonight...
--- /home/minfrin/src/apache/pristine/apache-1.3/src/main/http_protocol.c Tue
Mar 26 00:39:36 2002
+++ src/main/http_protocol.cSat Apr 6 14:57:49 2002
@@ -857,13 +857,13 @@
* then the actual input line exceeded the buffer length,
* and it would be a good idea for the caller to puke 400 or 414.
*/
-static int getline(char *s, int n, BUFF *in, int fold)
+API_EXPORT(int) ap_getline(char *s, int n, BUFF *in, int fold)
{
char *pos, next;
int retval;
int total = 0;
#ifdef CHARSET_EBCDIC
-/* When getline() is called, the HTTP protocol is in a state
+/* When ap_getline() is called, the HTTP protocol is in a state
* where we MUST be reading plain text protocol stuff,
* (Request line, MIME headers, Chunk sizes) regardless of
* the MIME type and conversion setting of the document itself.
@@ -978,7 +978,7 @@
static int read_request_line(request_rec *r)
{
-char l[DEFAULT_LIMIT_REQUEST_LINE + 2]; /* getline's two extra for \n\0 */
+char l[DEFAULT_LIMIT_REQUEST_LINE + 2]; /* ap_getline's two extra for \n\0 */
const char *ll = l;
const char *uri;
conn_rec *conn = r-connection;
@@ -1000,7 +1000,7 @@
* have to block during a read.
*/
ap_bsetflag(conn-client, B_SAFEREAD, 1);
-while ((len = getline(l, sizeof(l), conn-client, 0)) = 0) {
+while ((len = ap_getline(l, sizeof(l), conn-client, 0)) = 0) {
if ((len 0) || ap_bgetflag(conn-client, B_EOF)) {
ap_bsetflag(conn-client, B_SAFEREAD, 0);
/* this is a hack to make sure that request time is set,
@@ -1031,7 +1031,7 @@
ap_parse_uri(r, uri);
-/* getline returns (size of max buffer - 1) if it fills up the
+/* ap_getline returns (size of max buffer - 1) if it fills up the
* buffer before finding the end-of-line. This is only going to
* happen if it exceeds the configured limit for a request-line.
*/
@@ -1056,7 +1056,7 @@
static void get_mime_headers(request_rec *r)
{
-char field[DEFAULT_LIMIT_REQUEST_FIELDSIZE + 2]; /* getline's two extra */
+char field[DEFAULT_LIMIT_REQUEST_FIELDSIZE + 2]; /* ap_getline's two extra */
conn_rec *c = r-connection;
char *value;
char *copy;
@@ -1071,7 +1071,7 @@
* Read header lines until we get the empty separator line, a read error,
* the connection closes (EOF), reach the server limit, or we timeout.
*/
-while ((len = getline(field, sizeof(field), c-client, 1)) 0) {
+while ((len = ap_getline(field, sizeof(field), c-client, 1)) 0) {
if (r-server-limit_req_fields
(++fields_read r-server-limit_req_fields)) {
@@ -1081,7 +1081,7 @@
this server's limit.P\n);
return;
}
-/* getline returns (size of max buffer - 1) if it fills up the
+/* ap_getline returns (size of max buffer - 1) if it fills up the
* buffer before finding the end-of-line. This is only going to
* happen if it exceeds the configured limit for a field size.
*/
@@ -2018,7 +2018,7 @@
return 1;
}
-static long get_chunk_size(char *b)
+API_EXPORT(long) ap_get_chunk_size(char *b)
{
long chunksize = 0;
@@ -2100,14 +2100,14 @@
if (r-remaining == 0) {/* Start of new chunk */
-chunk_start = getline(buffer, bufsiz, r-connection-client, 0);
+chunk_start = ap_getline(buffer, bufsiz, r-connection-client, 0);
if ((chunk_start = 0) || (chunk_start = (bufsiz - 1))
|| !ap_isxdigit(*buffer)) {
r-connection-keepalive = -1;
return -1;
}
-len_to_read = get_chunk_size(buffer);
+len_to_read = ap_get_chunk_size(buffer);
if (len_to_read == 0) { /* Last chunk indicated, get footers */
if (r-read_body == REQUEST_CHUNKED_DECHUNK) {
@@ -2141,7 +2141,7 @@
len_read = chunk_start;
while ((bufsiz 1) ((len_read =
- getline(buffer, bufsiz, r-connection-client, 1)) 0)) {
+ ap_getline(buffer, bufsiz, r-connection-client, 1)) 0)) {
if (len_read != (bufsiz - 1)) {
buffer[len_read++] = CR;/* Restore footer line end */
smime.p7s
Description: S/MIME Cryptographic Signature
Re: [Patch] Namespace protect and export getline and get_chunk_size
+1 in concept.
Please add the exports to httpd.exp and bump the MMN Minor.
Bill
- Original Message -
From: Graham Leggett [EMAIL PROTECTED]
To: Apache Developers List [EMAIL PROTECTED]
Sent: Saturday, April 06, 2002 8:01 AM
Subject: [Patch] Namespace protect and export getline and get_chunk_size
Hi all,
In preparation for a bugfix to proxy and its broken chunking in v1.3, I
need to make getline() and get_chunk_size() available to proxy.
This patch namespace protects and exports these two functions. Will
commit later today if there are no objections...
Regards,
Graham
--
-
[EMAIL PROTECTED] There's a moon
over Bourbon Street
tonight...
--- /home/minfrin/src/apache/pristine/apache-1.3/src/main/http_protocol.c Tue Mar 26
00:39:36 2002
+++ src/main/http_protocol.c Sat Apr 6 14:57:49 2002
@@ -857,13 +857,13 @@
* then the actual input line exceeded the buffer length,
* and it would be a good idea for the caller to puke 400 or 414.
*/
-static int getline(char *s, int n, BUFF *in, int fold)
+API_EXPORT(int) ap_getline(char *s, int n, BUFF *in, int fold)
{
char *pos, next;
int retval;
int total = 0;
#ifdef CHARSET_EBCDIC
-/* When getline() is called, the HTTP protocol is in a state
+/* When ap_getline() is called, the HTTP protocol is in a state
* where we MUST be reading plain text protocol stuff,
* (Request line, MIME headers, Chunk sizes) regardless of
* the MIME type and conversion setting of the document itself.
@@ -978,7 +978,7 @@
static int read_request_line(request_rec *r)
{
-char l[DEFAULT_LIMIT_REQUEST_LINE + 2]; /* getline's two extra for \n\0 */
+char l[DEFAULT_LIMIT_REQUEST_LINE + 2]; /* ap_getline's two extra for \n\0 */
const char *ll = l;
const char *uri;
conn_rec *conn = r-connection;
@@ -1000,7 +1000,7 @@
* have to block during a read.
*/
ap_bsetflag(conn-client, B_SAFEREAD, 1);
-while ((len = getline(l, sizeof(l), conn-client, 0)) = 0) {
+while ((len = ap_getline(l, sizeof(l), conn-client, 0)) = 0) {
if ((len 0) || ap_bgetflag(conn-client, B_EOF)) {
ap_bsetflag(conn-client, B_SAFEREAD, 0);
/* this is a hack to make sure that request time is set,
@@ -1031,7 +1031,7 @@
ap_parse_uri(r, uri);
-/* getline returns (size of max buffer - 1) if it fills up the
+/* ap_getline returns (size of max buffer - 1) if it fills up the
* buffer before finding the end-of-line. This is only going to
* happen if it exceeds the configured limit for a request-line.
*/
@@ -1056,7 +1056,7 @@
static void get_mime_headers(request_rec *r)
{
-char field[DEFAULT_LIMIT_REQUEST_FIELDSIZE + 2]; /* getline's two extra */
+char field[DEFAULT_LIMIT_REQUEST_FIELDSIZE + 2]; /* ap_getline's two extra */
conn_rec *c = r-connection;
char *value;
char *copy;
@@ -1071,7 +1071,7 @@
* Read header lines until we get the empty separator line, a read error,
* the connection closes (EOF), reach the server limit, or we timeout.
*/
-while ((len = getline(field, sizeof(field), c-client, 1)) 0) {
+while ((len = ap_getline(field, sizeof(field), c-client, 1)) 0) {
if (r-server-limit_req_fields
(++fields_read r-server-limit_req_fields)) {
@@ -1081,7 +1081,7 @@
this server's limit.P\n);
return;
}
-/* getline returns (size of max buffer - 1) if it fills up the
+/* ap_getline returns (size of max buffer - 1) if it fills up the
* buffer before finding the end-of-line. This is only going to
* happen if it exceeds the configured limit for a field size.
*/
@@ -2018,7 +2018,7 @@
return 1;
}
-static long get_chunk_size(char *b)
+API_EXPORT(long) ap_get_chunk_size(char *b)
{
long chunksize = 0;
@@ -2100,14 +2100,14 @@
if (r-remaining == 0) {/* Start of new chunk */
-chunk_start = getline(buffer, bufsiz, r-connection-client, 0);
+chunk_start = ap_getline(buffer, bufsiz, r-connection-client, 0);
if ((chunk_start = 0) || (chunk_start = (bufsiz - 1))
|| !ap_isxdigit(*buffer)) {
r-connection-keepalive = -1;
return -1;
}
-len_to_read = get_chunk_size(buffer);
+len_to_read = ap_get_chunk_size(buffer);
if (len_to_read == 0) { /* Last chunk indicated, get footers */
if (r-read_body == REQUEST_CHUNKED_DECHUNK) {
@@ -2141,7 +2141,7 @@
len_read = chunk_start;
while ((bufsiz 1) ((len_read =
- getline(buffer, bufsiz, r-connection-client, 1)) 0)) {
+ ap_getline(buffer, bufsiz, r-connection-client,
Re: Questions about directories
* Austin Gonyou ([EMAIL PROTECTED]) wrote : I'm in the process of trying to build a RPM specfile for Apache2. I'm also trying to take my old configure line and put it into the apache 2 stuff..but there are some differences that bother me. I don't see a line for the htdocs path, icons path, etc... Is there any documentation on this stuff, rather, explanation? I've been using 2.0 for a while now..but I always put it into /some/dir/apache2, and everything goes under that. Trying to follow the LSB though, files go into many different places..combine that with RH, and it's pretty convoluted.. Have a look at config.layout and --enable-layout=blah. The Debian layout ought to be pretty close to what you need. Cheers, -Thom
Re: [Patch] Namespace protect and export getline and get_chunk_size
+1 Nice -I can use that in some modules I have here as well. Dw. -- Dirk-Willem van Gulik On Sat, 6 Apr 2002, Graham Leggett wrote: Hi all, In preparation for a bugfix to proxy and its broken chunking in v1.3, I need to make getline() and get_chunk_size() available to proxy. This patch namespace protects and exports these two functions. Will commit later today if there are no objections... Regards, Graham
Re: [Patch] Namespace protect and export getline and get_chunk_size
Bill Stoddard wrote:
+1 in concept.
Please add the exports to httpd.exp and bump the MMN Minor.
Like this?
Regards,
Graham
--
-
[EMAIL PROTECTED]There's a moon
over Bourbon Street
tonight...
--- /home/minfrin/src/apache/pristine/apache-1.3/src/support/httpd.exp Sun Mar 24
12:03:02 2002
+++ src/support/httpd.exp Sat Apr 6 15:22:44 2002
@@ -129,6 +129,7 @@
ap_fnmatch
ap_force_library_loading
ap_get_basic_auth_pw
+ap_get_chunk_size
ap_get_client_block
ap_get_gmtoff
ap_get_list_item
@@ -142,6 +143,7 @@
ap_get_time
ap_get_token
ap_get_virthost_addr
+ap_getline
ap_getparents
ap_getword
ap_getword_conf
--- /home/minfrin/src/apache/pristine/apache-1.3/src/include/ap_mmn.h Sun Mar 24
11:58:39 2002
+++ src/include/ap_mmn.hSat Apr 6 15:27:46 2002
@@ -235,6 +235,7 @@
*filter_callback to the end of buff.h
* 19990320.11 - Add some fields to the end of the core_dir_config
*structure
+ * 19990320.12 - add ap_getline(), ap_get_chunk_size()
*/
#define MODULE_MAGIC_COOKIE 0x41503133UL /* AP13 */
@@ -242,7 +243,7 @@
#ifndef MODULE_MAGIC_NUMBER_MAJOR
#define MODULE_MAGIC_NUMBER_MAJOR 19990320
#endif
-#define MODULE_MAGIC_NUMBER_MINOR 11/* 0...n */
+#define MODULE_MAGIC_NUMBER_MINOR 12/* 0...n */
/* Useful for testing for features. */
#define AP_MODULE_MAGIC_AT_LEAST(major,minor) \
--- /home/minfrin/src/apache/pristine/apache-1.3/src/main/http_protocol.c Tue
Mar 26 00:39:36 2002
+++ src/main/http_protocol.cSat Apr 6 14:57:49 2002
@@ -857,13 +857,13 @@
* then the actual input line exceeded the buffer length,
* and it would be a good idea for the caller to puke 400 or 414.
*/
-static int getline(char *s, int n, BUFF *in, int fold)
+API_EXPORT(int) ap_getline(char *s, int n, BUFF *in, int fold)
{
char *pos, next;
int retval;
int total = 0;
#ifdef CHARSET_EBCDIC
-/* When getline() is called, the HTTP protocol is in a state
+/* When ap_getline() is called, the HTTP protocol is in a state
* where we MUST be reading plain text protocol stuff,
* (Request line, MIME headers, Chunk sizes) regardless of
* the MIME type and conversion setting of the document itself.
@@ -978,7 +978,7 @@
static int read_request_line(request_rec *r)
{
-char l[DEFAULT_LIMIT_REQUEST_LINE + 2]; /* getline's two extra for \n\0 */
+char l[DEFAULT_LIMIT_REQUEST_LINE + 2]; /* ap_getline's two extra for \n\0 */
const char *ll = l;
const char *uri;
conn_rec *conn = r-connection;
@@ -1000,7 +1000,7 @@
* have to block during a read.
*/
ap_bsetflag(conn-client, B_SAFEREAD, 1);
-while ((len = getline(l, sizeof(l), conn-client, 0)) = 0) {
+while ((len = ap_getline(l, sizeof(l), conn-client, 0)) = 0) {
if ((len 0) || ap_bgetflag(conn-client, B_EOF)) {
ap_bsetflag(conn-client, B_SAFEREAD, 0);
/* this is a hack to make sure that request time is set,
@@ -1031,7 +1031,7 @@
ap_parse_uri(r, uri);
-/* getline returns (size of max buffer - 1) if it fills up the
+/* ap_getline returns (size of max buffer - 1) if it fills up the
* buffer before finding the end-of-line. This is only going to
* happen if it exceeds the configured limit for a request-line.
*/
@@ -1056,7 +1056,7 @@
static void get_mime_headers(request_rec *r)
{
-char field[DEFAULT_LIMIT_REQUEST_FIELDSIZE + 2]; /* getline's two extra */
+char field[DEFAULT_LIMIT_REQUEST_FIELDSIZE + 2]; /* ap_getline's two extra */
conn_rec *c = r-connection;
char *value;
char *copy;
@@ -1071,7 +1071,7 @@
* Read header lines until we get the empty separator line, a read error,
* the connection closes (EOF), reach the server limit, or we timeout.
*/
-while ((len = getline(field, sizeof(field), c-client, 1)) 0) {
+while ((len = ap_getline(field, sizeof(field), c-client, 1)) 0) {
if (r-server-limit_req_fields
(++fields_read r-server-limit_req_fields)) {
@@ -1081,7 +1081,7 @@
this server's limit.P\n);
return;
}
-/* getline returns (size of max buffer - 1) if it fills up the
+/* ap_getline returns (size of max buffer - 1) if it fills up the
* buffer before finding the end-of-line. This is only going to
* happen if it exceeds the configured limit for a field size.
*/
@@ -2018,7 +2018,7 @@
return 1;
}
-static long get_chunk_size(char *b)
+API_EXPORT(long) ap_get_chunk_size(char *b)
{
long chunksize = 0;
@@ -2100,14 +2100,14 @@
if (r-remaining == 0) {/* Start of new chunk */
-chunk_start = getline(buffer, bufsiz,
Re: [Patch] Namespace protect and export getline and get_chunk_size
Bill Stoddard wrote:
+1 in concept.
Please add the exports to httpd.exp and bump the MMN Minor.
Like this?
Yep!
Regards,
Graham
--
-
[EMAIL PROTECTED] There's a moon
over Bourbon Street
tonight...
--- /home/minfrin/src/apache/pristine/apache-1.3/src/support/httpd.exp Sun Mar 24
12:03:02 2002
+++ src/support/httpd.exp Sat Apr 6 15:22:44 2002
@@ -129,6 +129,7 @@
ap_fnmatch
ap_force_library_loading
ap_get_basic_auth_pw
+ap_get_chunk_size
ap_get_client_block
ap_get_gmtoff
ap_get_list_item
@@ -142,6 +143,7 @@
ap_get_time
ap_get_token
ap_get_virthost_addr
+ap_getline
ap_getparents
ap_getword
ap_getword_conf
--- /home/minfrin/src/apache/pristine/apache-1.3/src/include/ap_mmn.h Sun Mar 24
11:58:39 2002
+++ src/include/ap_mmn.h Sat Apr 6 15:27:46 2002
@@ -235,6 +235,7 @@
*filter_callback to the end of buff.h
* 19990320.11 - Add some fields to the end of the core_dir_config
*structure
+ * 19990320.12 - add ap_getline(), ap_get_chunk_size()
*/
#define MODULE_MAGIC_COOKIE 0x41503133UL /* AP13 */
@@ -242,7 +243,7 @@
#ifndef MODULE_MAGIC_NUMBER_MAJOR
#define MODULE_MAGIC_NUMBER_MAJOR 19990320
#endif
-#define MODULE_MAGIC_NUMBER_MINOR 11/* 0...n */
+#define MODULE_MAGIC_NUMBER_MINOR 12/* 0...n */
/* Useful for testing for features. */
#define AP_MODULE_MAGIC_AT_LEAST(major,minor) \
--- /home/minfrin/src/apache/pristine/apache-1.3/src/main/http_protocol.c Tue Mar 26
00:39:36 2002
+++ src/main/http_protocol.c Sat Apr 6 14:57:49 2002
@@ -857,13 +857,13 @@
* then the actual input line exceeded the buffer length,
* and it would be a good idea for the caller to puke 400 or 414.
*/
-static int getline(char *s, int n, BUFF *in, int fold)
+API_EXPORT(int) ap_getline(char *s, int n, BUFF *in, int fold)
{
char *pos, next;
int retval;
int total = 0;
#ifdef CHARSET_EBCDIC
-/* When getline() is called, the HTTP protocol is in a state
+/* When ap_getline() is called, the HTTP protocol is in a state
* where we MUST be reading plain text protocol stuff,
* (Request line, MIME headers, Chunk sizes) regardless of
* the MIME type and conversion setting of the document itself.
@@ -978,7 +978,7 @@
static int read_request_line(request_rec *r)
{
-char l[DEFAULT_LIMIT_REQUEST_LINE + 2]; /* getline's two extra for \n\0 */
+char l[DEFAULT_LIMIT_REQUEST_LINE + 2]; /* ap_getline's two extra for \n\0 */
const char *ll = l;
const char *uri;
conn_rec *conn = r-connection;
@@ -1000,7 +1000,7 @@
* have to block during a read.
*/
ap_bsetflag(conn-client, B_SAFEREAD, 1);
-while ((len = getline(l, sizeof(l), conn-client, 0)) = 0) {
+while ((len = ap_getline(l, sizeof(l), conn-client, 0)) = 0) {
if ((len 0) || ap_bgetflag(conn-client, B_EOF)) {
ap_bsetflag(conn-client, B_SAFEREAD, 0);
/* this is a hack to make sure that request time is set,
@@ -1031,7 +1031,7 @@
ap_parse_uri(r, uri);
-/* getline returns (size of max buffer - 1) if it fills up the
+/* ap_getline returns (size of max buffer - 1) if it fills up the
* buffer before finding the end-of-line. This is only going to
* happen if it exceeds the configured limit for a request-line.
*/
@@ -1056,7 +1056,7 @@
static void get_mime_headers(request_rec *r)
{
-char field[DEFAULT_LIMIT_REQUEST_FIELDSIZE + 2]; /* getline's two extra */
+char field[DEFAULT_LIMIT_REQUEST_FIELDSIZE + 2]; /* ap_getline's two extra */
conn_rec *c = r-connection;
char *value;
char *copy;
@@ -1071,7 +1071,7 @@
* Read header lines until we get the empty separator line, a read error,
* the connection closes (EOF), reach the server limit, or we timeout.
*/
-while ((len = getline(field, sizeof(field), c-client, 1)) 0) {
+while ((len = ap_getline(field, sizeof(field), c-client, 1)) 0) {
if (r-server-limit_req_fields
(++fields_read r-server-limit_req_fields)) {
@@ -1081,7 +1081,7 @@
this server's limit.P\n);
return;
}
-/* getline returns (size of max buffer - 1) if it fills up the
+/* ap_getline returns (size of max buffer - 1) if it fills up the
* buffer before finding the end-of-line. This is only going to
* happen if it exceeds the configured limit for a field size.
*/
@@ -2018,7 +2018,7 @@
return 1;
}
-static long get_chunk_size(char *b)
+API_EXPORT(long) ap_get_chunk_size(char *b)
{
long chunksize = 0;
@@ -2100,14 +2100,14 @@
if (r-remaining == 0) {/* Start of new chunk */
-
[Patch] PR7513: Chunking fixed in proxy
Hi all,
This patch fixes the broken chunking problem in the v1.3 proxy by adding
dechunk support to ap_proxy_send_fb(), support for which was missing
from the code.
It also removes hop-by-hop headers from the server response before
passing them up to the client. Previously hop-by-hop headers were only
removed for the request.
There is a question within the patch whether EBCDIC is supported
correctly while dechunking - Can an IBM person take a look at this and
tell me if I did the right thing?
Regards,
Graham
--
-
[EMAIL PROTECTED]There's a moon
over Bourbon Street
tonight...
diff -u -r /home/minfrin/src/apache/pristine/apache-1.3/src/modules/proxy/mod_proxy.h
src/modules/proxy/mod_proxy.h
--- /home/minfrin/src/apache/pristine/apache-1.3/src/modules/proxy/mod_proxy.h Sun
Mar 24 12:00:53 2002
+++ src/modules/proxy/mod_proxy.h Sat Apr 6 11:12:59 2002
@@ -297,7 +297,7 @@
char **passwordp, char **hostp, int *port);
const char *ap_proxy_date_canon(pool *p, const char *x);
table *ap_proxy_read_headers(request_rec *r, char *buffer, int size, BUFF *f);
-long int ap_proxy_send_fb(BUFF *f, request_rec *r, cache_req *c, off_t len, int
nowrite, size_t recv_buffer_size);
+long int ap_proxy_send_fb(BUFF *f, request_rec *r, cache_req *c, off_t len, int
+nowrite, int chunked, size_t recv_buffer_size);
void ap_proxy_write_headers(cache_req *c, const char *respline, table *t);
int ap_proxy_liststr(const char *list, const char *key, char **val);
void ap_proxy_hash(const char *it, char *val, int ndepth, int nlength);
diff -u -r
/home/minfrin/src/apache/pristine/apache-1.3/src/modules/proxy/proxy_cache.c
src/modules/proxy/proxy_cache.c
--- /home/minfrin/src/apache/pristine/apache-1.3/src/modules/proxy/proxy_cache.c
Sat Apr 6 15:15:06 2002
+++ src/modules/proxy/proxy_cache.c Sat Apr 6 16:37:51 2002
@@ -719,7 +719,7 @@
*
* We don't yet understand If-Range, but we will...
*/
-int ap_proxy_cache_conditional(request_rec *r, cache_req *c, BUFF *cachefp){
+int ap_proxy_cache_conditional(request_rec *r, cache_req *c, BUFF *cachefp) {
const char *etag, *wetag = NULL;
/* get etag */
@@ -784,7 +784,7 @@
/* if cache file is being updated */
if (c-origfp) {
ap_proxy_write_headers(c, c-resp_line, c-hdrs);
-ap_proxy_send_fb(c-origfp, r, c, c-len, 1, IOBUFSIZE);
+ap_proxy_send_fb(c-origfp, r, c, c-len, 1, 0, IOBUFSIZE);
ap_proxy_cache_tidy(c);
}
else
@@ -855,7 +855,7 @@
/* are we updating the cache file? */
if (c-origfp) {
ap_proxy_write_headers(c, c-resp_line, c-hdrs);
-ap_proxy_send_fb(c-origfp, r, c, c-len, 1, IOBUFSIZE);
+ap_proxy_send_fb(c-origfp, r, c, c-len, 1, 0, IOBUFSIZE);
ap_proxy_cache_tidy(c);
}
else
@@ -884,14 +884,14 @@
/* are we rewriting the cache file? */
if (c-origfp) {
ap_proxy_write_headers(c, c-resp_line, c-hdrs);
-ap_proxy_send_fb(c-origfp, r, c, c-len, r-header_only, IOBUFSIZE);
+ap_proxy_send_fb(c-origfp, r, c, c-len, r-header_only, 0, IOBUFSIZE);
ap_proxy_cache_tidy(c);
return OK;
}
/* no, we not */
if (!r-header_only) {
-ap_proxy_send_fb(cachefp, r, NULL, c-len, 0, IOBUFSIZE);
+ap_proxy_send_fb(cachefp, r, NULL, c-len, 0, 0, IOBUFSIZE);
}
else {
ap_pclosef(r-pool, ap_bfileno(cachefp, B_WR));
diff -u -r /home/minfrin/src/apache/pristine/apache-1.3/src/modules/proxy/proxy_ftp.c
src/modules/proxy/proxy_ftp.c
--- /home/minfrin/src/apache/pristine/apache-1.3/src/modules/proxy/proxy_ftp.c Tue
Mar 26 00:29:03 2002
+++ src/modules/proxy/proxy_ftp.c Sat Apr 6 11:10:54 2002
@@ -1355,7 +1355,7 @@
/* we need to set this for ap_proxy_send_fb()... */
if (c != NULL)
c-cache_completion = 0;
-ap_proxy_send_fb(data, r, c, -1, 0, conf-io_buffer_size);
+ap_proxy_send_fb(data, r, c, -1, 0, 0, conf-io_buffer_size);
}
else {
send_dir(data, r, c, cwd);
diff -u -r /home/minfrin/src/apache/pristine/apache-1.3/src/modules/proxy/proxy_http.c
src/modules/proxy/proxy_http.c
--- /home/minfrin/src/apache/pristine/apache-1.3/src/modules/proxy/proxy_http.c Tue
Mar 26 00:29:06 2002
+++ src/modules/proxy/proxy_http.c Sat Apr 6 16:41:17 2002
@@ -164,6 +164,7 @@
char portstr[32];
pool *p = r-pool;
int destport = 0;
+int chunked = 0;
char *destportstr = NULL;
const char *urlptr = NULL;
const char *datestr, *urlstr;
@@ -476,7 +477,12 @@
);
}
-/* strip
Re: cvs commit httpd-2.0/modules/filters/mod_include.c
Sorry for the lack of timeliness on responding to this. Our mailserver has been about to be back up any minute now for a couple of days. The test case that I ran was even more brutal than what your test module does. Basically I have a small piece of code that puts each byte in its own bucket and each bucket in its own brigade. Brian's patch will not handle this case because there is no next bucket to point tag_start_index at. I was a little vague in my description of the problem. Basically, if the !--# tag occurs at the end of one brigade and the directive starts at the beginning of the next brigade we have trouble. In my tests this was causing a core dump which my patch fixed. I'm also surprised that the include virtual was failing since it passed my tests. :( I'll double check those results to see if I missed something. Also, Brian, I do not see where the comment you removed was invalid. Slen is only ever set to ctx-start_seq_len (which by default is 5 I believe). Slen is never changed to be any number other than ctx-start_seq_len. I do not claim to have studied bndm enough to be certain, but it seems to me that if the brigade has a single bucket with a single byte which hapens to match within the pattern then you will end up incrementing ctx-bytes_parsed by pos+slen (where slen == 5) when only one byte was processed. That is to say, len == 1, so it will enter the if (len) conditional block around line 472. Bndm can match the pattern and return pos = 0, so it enters the (pos != len) conditional block. At the end of this block it increments ctx-bytes_parsed by pos+slen even though it only processed one byte. The previous bytes will have already been accounted for during runs through find_start_sequence for previous brigades. Where am I confused? Sorry again for the delay in responding. Paul J. Reder
Re: [Patch] Namespace protect and export getline and get_chunk_size
Graham Leggett wrote: Hi all, In preparation for a bugfix to proxy and its broken chunking in v1.3, I need to make getline() and get_chunk_size() available to proxy. This patch namespace protects and exports these two functions. Will commit later today if there are no objections... +1 Somewhat OT: I'd like to shoot for a 1.3 release to address all known bugs later this month. At that point, we can formally make 1.3 maint. mode only. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: [Patch] Namespace protect and export getline and get_chunk_size
Jim Jagielski wrote: Somewhat OT: I'd like to shoot for a 1.3 release to address all known bugs later this month. At that point, we can formally make 1.3 maint. mode only. Apart from the chunking problem, the proxy doesn't support 100-continue yet (which I am working on now), and it doesn't support Cache-Control: no-cache=header. Once these two things are in, HTTP/1.1 support will be complete and everything from then on is a bigfix. This should be done within the next week or so... Regards, Graham -- - [EMAIL PROTECTED]There's a moon over Bourbon Street tonight... smime.p7s Description: S/MIME Cryptographic Signature
Re: cvs commit httpd-2.0/modules/filters/mod_include.c
Paul Reder wrote: Sorry for the lack of timeliness on responding to this. Our mailserver has been about to be back up any minute now for a couple of days. The test case that I ran was even more brutal than what your test module does. Basically I have a small piece of code that puts each byte in its own bucket and each bucket in its own brigade. Brian's patch will not handle this case because there is no next bucket to point tag_start_index at The next bucket in this case is the brigade sentinel, which is the same thing that send_parsed_content() would choose as the next bucket to scan if we escaped from find_start_sequence() with tag_start_index==NULL. I was a little vague in my description of the problem. Basically, if the !--# tag occurs at the end of one brigade and the directive starts at the beginning of the next brigade we have trouble. In my tests this was causing a core dump which my patch fixed. I'm also surprised that the include virtual was failing since it passed my tests. :( I'll double check those results to see if I missed something. Also, Brian, I do not see where the comment you removed was invalid. Slen is only ever set to ctx-start_seq_len (which by default is 5 I believe). Slen is never changed to be any number other than ctx-start_seq_len. I do not claim to have studied bndm enough to be certain, but it seems to me that if the brigade has a single bucket with a single byte which hapens to match within the pattern then you will end up incrementing ctx-bytes_parsed by pos+slen (where slen == 5) when only one byte was processed. bndm will only match on an instance of the complete pattern within the current bucket. If slen==5 and len==1, bndm won't find a match. All the one-byte-at-a-time scanning code in find_start_sequence() exists solely to catch the boundary cases where the pattern spans two or more buckets--the cases that bndm won't detect. So when bndm finds a match, it's guaranteed that len = slen. If len==1 and bndm indicates that it's found a pattern, it can only mean that the pattern has been changed from !--# to some single-byte token. This case *is* possible, now that we support the SSIStartTag directive. But the logic for incrementing ctx-bytes_parsed by pos+slen is still correct; pos+slen==1. --Brian
[PATCH] Correct APXS behavior in non-standard layout installations
This patch will fix a couple of problems I found when building modules using APXS when Apache 2.0 is installed not following a custom layout (but a weird one like my DarwinBundle). Pie patch.apxs.txt Description: Binary data
[PATCH] Add libdir entries in config.layout...
We forgot to put libdir in config.layout, it's nice to have it around there as well (looks better when non-standard layouts are used). Pier
[PATCH] Add --includedir to configure.in
This needs to be specified, otherwise headers will go into weird locations when doing a make install... Pier patch.configure.txt Description: Binary data
Re: [PATCH] Add libdir entries in config.layout...
Pier Fumagalli [EMAIL PROTECTED] wrote: We forgot to put libdir in config.layout, it's nice to have it around there as well (looks better when non-standard layouts are used). Shit, sometimes I should click that Add Attachment on my mail client :) Pier patch.layout.txt Description: Binary data
Question about this patch to core_input_filter...
Justin,
This is your patch... core_input_filter adds a socket bucket, does a
APR_BRIGADE_NORMALIZE
and then calls APR_BRIGADE_EMPTY(). How can this check ever return an empty brigade?
Bill
===
RCS file: /home/cvspublic/httpd-2.0/server/core.c,v
retrieving revision 1.144
retrieving revision 1.145
diff -u -r1.144 -r1.145
--- httpd-2.0/server/core.c 2002/02/05 22:56:44 1.144
+++ httpd-2.0/server/core.c 2002/02/06 02:24:18 1.145
-3062,9 +3062,13
/* ### This is bad. */
APR_BRIGADE_NORMALIZE(ctx-b);
-/* check for empty brigade *AFTER* APR_BRIGADE_NORMALIZE() */
+/* check for empty brigade *AFTER* APR_BRIGADE_NORMALIZE()
+ * If we have lost our socket bucket (see above), we are EOF.
+ *
+ * Ideally, this should be returning SUCCESS with EOS bucket, but
+ * some higher-up APIs (spec. read_request_line via ap_rgetline)
+ * want an error code. */
if (APR_BRIGADE_EMPTY(ctx-b)) {
-/* hit EOF on socket already */
return APR_EOF;
}
-3150,6 +3154,22
}
else if (rv != APR_SUCCESS) {
return rv;
+} else if (block == APR_BLOCK_READ len == 0) {
+/* We wanted to read some bytes in blocking mode. We read
+ * 0 bytes. Hence, we now assume we are EOS.
+ *
+ * When we are in normal mode, return an EOS bucket to the
+ * caller.
+ * When we are in speculative mode, leave ctx-b empty, so
+ * that the next call returns an EOS bucket.
+ */
+apr_bucket_delete(e);
+
+if (mode == AP_MODE_READBYTES) {
+e = apr_bucket_eos_create();
+APR_BRIGADE_INSERT_TAIL(b, e);
+}
+return APR_SUCCESS;
}
/* We can only return at most what we read. */
Re: Question about this patch to core_input_filter...
Justin, This is your patch... core_input_filter adds a socket bucket, does a APR_BRIGADE_NORMALIZE and then calls APR_BRIGADE_EMPTY(). How can this check ever return an empty brigade? Bill === RCS file: /home/cvspublic/httpd-2.0/server/core.c,v retrieving revision 1.144 retrieving revision 1.145 diff -u -r1.144 -r1.145 --- httpd-2.0/server/core.c 2002/02/05 22:56:44 1.144 +++ httpd-2.0/server/core.c 2002/02/06 02:24:18 1.145 -3062,9 +3062,13 /* ### This is bad. */ APR_BRIGADE_NORMALIZE(ctx-b); -/* check for empty brigade *AFTER* APR_BRIGADE_NORMALIZE() */ +/* check for empty brigade *AFTER* APR_BRIGADE_NORMALIZE() + * If we have lost our socket bucket (see above), we are EOF. Let me ask a different way... Referring to the comment above, how can we loose a socket bucket that was just created? Thanks, Bill
FW: Official Release: Apache 2.0.35 is now GA
I like receving messages like this. :'-) Ryan -- Ryan Bloom [EMAIL PROTECTED] 645 Howard St. [EMAIL PROTECTED] San Francisco, CA -Original Message- From: Mario Guerra [mailto:[EMAIL PROTECTED]] Sent: Saturday, April 06, 2002 10:31 AM To: Ryan Bloom Subject: Re: Official Release: Apache 2.0.35 is now GA On Fri, 5 Apr 2002, Ryan Bloom wrote: It's my pleasure to announce that the Apache Software Foundation's Apache HTTP Server, version 2.0.35, has now been released for General Availability. Congratulations to the Apache Group for this milestone (and all that excellent work they are doing). Mario Guerra
Re: Does Solaris qsort suck
On Sat, 6 Apr 2002, Yusuf Goolamabbas wrote: Well, That seems to be the view if one reads the following threads at the postgres mailing list and Sun's developer connection http://archives.postgresql.org/pgsql-hackers/2002-04/msg00103.php http://forum.sun.com/thread.jsp?forum=4thread=7231 Don't know if those cases would be seen by Solaris users of Apache 2.0.x, but it might be useful to snarf FreeBSD's qsort.c and link Apache to it if a Solaris platform is detected I think Apache does not sort more then ten items so this bug does not affect Apache. Igor Sysoev
RE: Question about this patch to core_input_filter...
Justin, This is your patch... core_input_filter adds a socket bucket, does a APR_BRIGADE_NORMALIZE and then calls APR_BRIGADE_EMPTY(). How can this check ever return an empty brigade? If the socket is closed on the other side, then the bucket code will remove the socket from the brigade. Ryan
Re: [PATCH] Correct APXS behavior in non-standard layoutinstallations
Pier Fumagalli [EMAIL PROTECTED] wrote: This patch will fix a couple of problems I found when building modules using APXS when Apache 2.0 is installed not following a custom layout (but a weird one like my DarwinBundle). Thom actually showed me his patch posted as Subject: [PATCH] Fix apxs so it is relocatable... Message-ID: 20020401184143.GA9215@eustasy It works great for me on my wicked installation layout, and today we fixed another couple of things left from his patch (a couple of hardcoded build directories were still in, and it wasn't properly resolving the ServerRoot when apxs was called from a symlink)... This is the revised and updated patch... Pier / Thom :) patch.apxs.txt Description: Binary data
RE: Question about this patch to core_input_filter...
On Sat, 6 Apr 2002, Ryan Bloom wrote: Justin, This is your patch... core_input_filter adds a socket bucket, does a APR_BRIGADE_NORMALIZE and then calls APR_BRIGADE_EMPTY(). How can this check ever return an empty brigade? If the socket is closed on the other side, then the bucket code will remove the socket from the brigade. Right. Well, more precisely, it morphs itself to a zero-length immortal bucket, which is then removed from the brigade by APR_BRIGADE_NORMALIZE. --Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
RE: 2.0.35 related: Website tweak, upgrade apache.org servers
On Sat, 6 Apr 2002, Mladen Turk wrote: http://httpd.apache.org still shows: Apache 1.3.24 is the best version of Apache currently available; everyone running 1.2.X servers or earlier are strongly urged to upgrade to 1.3, as there will not be any further 1.2.X releases. At present, the Win32 port of Apache is not as stable as the UNIX version. Whoops, sorry, forgot to look at that part. I just removed that whole paragraph. --Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
Re: [Patch] Namespace protect and export getline and get_chunk_size
+1 here too, but please also decorate with API_EXPORT() fooness and
add to the appropriate entries to ApacheCore.def/ApacheCoreNW.def files.
At 07:21 AM 4/6/2002, you wrote:
+1 in concept.
Please add the exports to httpd.exp and bump the MMN Minor.
Bill
- Original Message -
From: Graham Leggett [EMAIL PROTECTED]
To: Apache Developers List [EMAIL PROTECTED]
Sent: Saturday, April 06, 2002 8:01 AM
Subject: [Patch] Namespace protect and export getline and get_chunk_size
Hi all,
In preparation for a bugfix to proxy and its broken chunking in v1.3, I
need to make getline() and get_chunk_size() available to proxy.
This patch namespace protects and exports these two functions. Will
commit later today if there are no objections...
Regards,
Graham
--
-
[EMAIL PROTECTED] There's a moon
over Bourbon Street
tonight...
---
/home/minfrin/src/apache/pristine/apache-1.3/src/main/http_protocol.c Tue
Mar 26
00:39:36 2002
+++ src/main/http_protocol.c Sat Apr 6 14:57:49 2002
@@ -857,13 +857,13 @@
* then the actual input line exceeded the buffer length,
* and it would be a good idea for the caller to puke 400 or 414.
*/
-static int getline(char *s, int n, BUFF *in, int fold)
+API_EXPORT(int) ap_getline(char *s, int n, BUFF *in, int fold)
{
char *pos, next;
int retval;
int total = 0;
#ifdef CHARSET_EBCDIC
-/* When getline() is called, the HTTP protocol is in a state
+/* When ap_getline() is called, the HTTP protocol is in a state
* where we MUST be reading plain text protocol stuff,
* (Request line, MIME headers, Chunk sizes) regardless of
* the MIME type and conversion setting of the document itself.
@@ -978,7 +978,7 @@
static int read_request_line(request_rec *r)
{
-char l[DEFAULT_LIMIT_REQUEST_LINE + 2]; /* getline's two extra for
\n\0 */
+char l[DEFAULT_LIMIT_REQUEST_LINE + 2]; /* ap_getline's two extra
for \n\0 */
const char *ll = l;
const char *uri;
conn_rec *conn = r-connection;
@@ -1000,7 +1000,7 @@
* have to block during a read.
*/
ap_bsetflag(conn-client, B_SAFEREAD, 1);
-while ((len = getline(l, sizeof(l), conn-client, 0)) = 0) {
+while ((len = ap_getline(l, sizeof(l), conn-client, 0)) = 0) {
if ((len 0) || ap_bgetflag(conn-client, B_EOF)) {
ap_bsetflag(conn-client, B_SAFEREAD, 0);
/* this is a hack to make sure that request time is set,
@@ -1031,7 +1031,7 @@
ap_parse_uri(r, uri);
-/* getline returns (size of max buffer - 1) if it fills up the
+/* ap_getline returns (size of max buffer - 1) if it fills up the
* buffer before finding the end-of-line. This is only going to
* happen if it exceeds the configured limit for a request-line.
*/
@@ -1056,7 +1056,7 @@
static void get_mime_headers(request_rec *r)
{
-char field[DEFAULT_LIMIT_REQUEST_FIELDSIZE + 2]; /* getline's two
extra */
+char field[DEFAULT_LIMIT_REQUEST_FIELDSIZE + 2]; /* ap_getline's
two extra */
conn_rec *c = r-connection;
char *value;
char *copy;
@@ -1071,7 +1071,7 @@
* Read header lines until we get the empty separator line, a read
error,
* the connection closes (EOF), reach the server limit, or we timeout.
*/
-while ((len = getline(field, sizeof(field), c-client, 1)) 0) {
+while ((len = ap_getline(field, sizeof(field), c-client, 1)) 0) {
if (r-server-limit_req_fields
(++fields_read r-server-limit_req_fields)) {
@@ -1081,7 +1081,7 @@
this server's limit.P\n);
return;
}
-/* getline returns (size of max buffer - 1) if it fills up the
+/* ap_getline returns (size of max buffer - 1) if it fills up the
* buffer before finding the end-of-line. This is only going to
* happen if it exceeds the configured limit for a field size.
*/
@@ -2018,7 +2018,7 @@
return 1;
}
-static long get_chunk_size(char *b)
+API_EXPORT(long) ap_get_chunk_size(char *b)
{
long chunksize = 0;
@@ -2100,14 +2100,14 @@
if (r-remaining == 0) {/* Start of new chunk */
-chunk_start = getline(buffer, bufsiz, r-connection-client, 0);
+chunk_start = ap_getline(buffer, bufsiz,
r-connection-client, 0);
if ((chunk_start = 0) || (chunk_start = (bufsiz - 1))
|| !ap_isxdigit(*buffer)) {
r-connection-keepalive = -1;
return -1;
}
-len_to_read = get_chunk_size(buffer);
+len_to_read = ap_get_chunk_size(buffer);
if (len_to_read == 0) { /* Last chunk indicated, get footers */
RE: 2.0.35 related: Website tweak, upgrade apache.org servers
At 06:18 AM 4/6/2002, you wrote: From: Mladen Turk [mailto:[EMAIL PROTECTED]] Sent: 06 April 2002 13:53 What bothers me is the statement the Win32 port of Apache is not as stable as the UNIX version. This is not in the 2.0 part of the page. This only goes for 1.3. In the 2.0 section: This version of Apache is known to work on many versions of Unix, BeOS, OS/2, Windows, and Netware. Because of many of the advancements in Apache 2.0, the initial release of Apache is expected to perform equally well on all supported platforms Exactly the point. The 1.3 Win32 port is certainly not as stable or robust as Unix... that warning [whenever 1.3 is mentioned] is still needed. And on the other hand what is the Win32 port? Is it Windows 95, Windows NT 4, 2000, or XP? I think that we can safely assume that Apache 2.0 was targetted at Windows NT 4 and up. I personally wouldn't want to have to worry about Windows 9x (for obvious reasons I think). Correct. Win9x has never been 'supported' [surprize] but we have always taken the position, if it works for you, great. Pre-9x won't work at all, WinNT 4.0 SP5 or later is required for WinSock2 and some other bugs. WinXP has a broken afd.sys that must be patched. Some 3rd party VPN clients are borked. So we can't really say This Just Works on every OS... but hopefully the easier query and filing options in Bugzilla will help folks identify specific problems with specific Win9x or even Netware, OS2 and Unix family kernels. Bill Bill
Re: [PATCH] Add libdir entries in config.layout...
On Sat, Apr 06, 2002 at 06:33:38PM +0100, Pier Fumagalli wrote: Pier Fumagalli [EMAIL PROTECTED] wrote: We forgot to put libdir in config.layout, it's nice to have it around there as well (looks better when non-standard layouts are used). committed, thanks. :) -aaron
Difficulties with SSL and mod_proxy
I am having trouble with certain combinations of SSL and mod_proxy.
If I have apache 2.0 acting as an SSL enabled server, I can get it
to proxy to a remote SSL server but NOT to a remote clear text server.
So, while this configuration works:
ProxyPass /foo/ https://otherhost/bar
SSLProxyEngin On
.. etc ...
This does not:
ProxyPass /foo/ http://otherhost/bar
I seem to recall this working several releases ago.
I'm not sure where to look on this, but here are some more details:
1) Apache clearly makes the TCP connection to the downstream server
but doesn't actualy send any data.
2) After the connection to the downstream server is made, it seems to just
freeze waiting for input. Here is a stacktrace taken when it has reached
this state (this is not a segfault or anything):
0x402b00ee in __select () from /lib/i686/libc.so.6
(gdb) bt
#0 0x402b00ee in __select () from /lib/i686/libc.so.6
#1 0x40043e14 in __DTOR_END__ () at eval.c:41
#2 0x40038325 in apr_recv () at eval.c:41
#3 0x4001d256 in socket_read () at eval.c:41
#4 0x080c6f76 in core_input_filter (f=0x827ba00, b=0x827b9c0, mode=AP_MODE_READBYTES,
block=APR_BLOCK_READ, readbytes=11) at core.c:3430
#5 0x080be000 in ap_get_brigade (next=0x827ba00, bb=0x827b9c0,
mode=AP_MODE_READBYTES, block=APR_BLOCK_READ, readbytes=11) at util_filter.c:508
#6 0x0808adca in bio_bucket_in_read (bio=0x8227388, in=0x8281ec8 , inl=11) at
ssl_engine_io.c:395
#7 0x080fa95d in BIO_read () at eval.c:41
Cannot access memory at address 0xb
(gdb) up 4
#4 0x080c6f76 in core_input_filter (f=0x827ba00, b=0x827b9c0, mode=AP_MODE_READBYTES,
block=APR_BLOCK_READ, readbytes=11) at core.c:3430
3430rv = apr_bucket_read(e, str, len, block);
(gdb) print *f
$1 = {frec = 0x8195b90, ctx = 0x827b9f0, next = 0x0, r = 0x0, c = 0x823e280}
There's a little bit of wierdness here. This is a single process httpd, not threaded.
The connection the filter is attached to is that of mod_proxy to the downstream server
which is not SUPPOSED to be SSL. The filter stack on this connection is ssl/tls
filter,
then core_in. Since the downstream is not an SSL server, this seems incorrect.
Also, at this stage, no data has been sent to the downstream server, so waiting on
input
from the connection doesn't make sense.
Any pointers here would be helpfull as I am not sure where to look.
-adam
Re: cvs commit: httpd-2.0 config.layout
On Sun, Apr 07, 2002 at 01:13:17AM +0100, Pier Fumagalli wrote: Thanks Aaron... :) Much appreciated... Check out the --includedir as well. I applied that one but forgot to commit. All taken care of now. I've review the APXS patch from you and Thom, and it seems to work for me w/ PHP4, so I'll commit that too shortly. -aaron
Re: SSL with NameVirtualHosts?
It is possible with HTTP/1.1, just not implemented http://www.ietf.org/rfc/rfc2817.txt I know that the docs say it's not possible, but is it theoretically possible? No. Not with SSL, at least. http://www.modssl.org/docs/2.8/ssl_faq.html#ToC47 -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
