Re: config/3520: Variable in Configuration
[In order for any reply to be added to the PR database, ]
[you need to include [EMAIL PROTECTED] in the Cc line ]
[and leave the subject line UNCHANGED. This is not done]
[automatically because of the potential for mail loops. ]
[If you do not include this Cc, your reply may be ig- ]
[nored unless you are responding to an explicit request ]
[from a developer. ]
[Reply only with text; DO NOT SEND ATTACHMENTS! ]
Synopsis: Variable in Configuration
State-Changed-From-To: open-closed
State-Changed-By: rse
State-Changed-When: Wed Mar 10 02:52:24 PST 1999
State-Changed-Why:
This is now possible with the help of mod_define.
Your setvar is named define there and
@@xxx@@ can be written as ${xxx}. You can find it inside
http://www.apache.org/dist/contrib/modules/1.3/apache-contrib-1.0.3.tar.gz
Re: config/3956: Apache's configure script break under new versions of grep
The following reply was made to PR config/3956; it has been noted by GNATS. From: Ralf S. Engelschall [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Subject: Re: config/3956: Apache's configure script break under new versions of grep Date: Wed, 10 Mar 1999 12:08:27 +0100 In article [EMAIL PROTECTED] you wrote: Environment: Linux 2.0.36, glibc 2.0.7u intel x86 Description: When using gnu grep beyond version 2.2 such as the current stable version (2.3), the configure script with Apache will break. No modules are recognized as valid and the configure script will not complete. How-To-Repeat: Just run ./configure --prefix=usr/local/apache using grep 2.3 and it'll fail. Fix: Not really but if you find a fix, please email me. I've tried this and I cannot reproduce this failure: | : which grep | /tmp/grep | [EMAIL PROTECTED]:/e/apache/SRC/apache-1.3 | : /tmp/grep -V | grep (GNU grep) 2.3 | | Copyright (C) 1988, 1992-1998, 1999 Free Software Foundation, Inc. | This is free software; see the source for copying conditions. There is NO | warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. | | [EMAIL PROTECTED]:/e/apache/SRC/apache-1.3 | : ./config.status | Configuring for Apache, Version 1.3.5-dev | + using installation path layout: GNU (config.layout) | Creating Makefile | Creating Configuration.apaci in src | Creating Makefile in src | + configured for FreeBSD 3.1 platform | + setting C pre-processor to cc -E | + checking for system header files | + using custom target name: apache | + adding selected modules | o rewrite_module uses ConfigStart/End | enabling DBM support for mod_rewrite | o dbm_auth_module uses ConfigStart/End | o db_auth_module uses ConfigStart/End | using Berkeley-DB/1.x for mod_auth_db (-lc) | + enabling generation of Apache core as DSO | + doing sanity check on compiler and options | Creating Makefile in src/support | Creating Makefile in src/main | Creating Makefile in src/ap | Creating Makefile in src/regex | Creating Makefile in src/os/unix | Creating Makefile in src/modules/experimental | Creating Makefile in src/modules/standard | Creating Makefile in src/modules/proxy | Creating Makefile in src/modules/example So it seems like your vendor's grep installation is broken. At least also from the grep usages in our scripts I cannot image why it should fail. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com
Re: config/3823: enabling a module as shared does not cause it to link against the necessary extra libraries
The following reply was made to PR config/3823; it has been noted by GNATS. From: Ralf S. Engelschall [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Subject: Re: config/3823: enabling a module as shared does not cause it to link against the necessary extra libraries Date: Wed, 10 Mar 1999 11:57:40 +0100 In article [EMAIL PROTECTED] you wrote: Given a module with a configuration like this, APACI configuration finds that it does need to link the additional libraries: * MODULE-DEFINITION-START * Name: mysql_auth_module * ConfigStart MYSQL_LIB=-L/usr/local/lib/mysql -lmysqlclient -lm if [ X$MYSQL_LIB != X ]; then LIBS=$LIBS $MYSQL_LIB echo + using $MYSQL_LIB for MySQL support fi * ConfigEnd * MODULE-DEFINITION-END This works fine when this module is compiled statically. However, if you make this module --enable-shared during the config, then the resulting .so file does not have the additional libraries linked, but those libraries are referenced for linking when building httpd. It's not such easy because usually you cannot link DSO's against other DSOs (i.e. shared libraries here). To solve the problem you either have to build this MySQL module statically or build on a smart platform (usually all ELF-based platforms are of this type where you can link a DSO against a DSO) and use --enable-rule=SHARED_CHAIN. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com
Re: config/3958: configure silently ignores --enable-XXX options where XXX is unknown
The following reply was made to PR config/3958; it has been noted by GNATS. From: Ralf S. Engelschall [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Subject: Re: config/3958: configure silently ignores --enable-XXX options where XXX is unknown Date: Wed, 10 Mar 1999 12:16:35 +0100 In article [EMAIL PROTECTED] you wrote: If I mistype: ./configure --enable-module=mod-speling as: ./configure --enable-modules=mod-speling I get no error, but apache builds without mod-speling. In fact --enable-XXX is ignored if XXX is unknown. I think this deserves an error message to avoid the pitfall of mis-spelling a --enable-XXX option and having it ignored. There are similar issues for --disable-XXX. Thanks for catching this. The suggested error handling is now added for Apache 1.3.5. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com
Re: config/4010: ./configure --enable-shared is broken
The following reply was made to PR config/4010; it has been noted by GNATS. From: Ralf S. Engelschall [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Subject: Re: config/4010: ./configure --enable-shared is broken Date: Wed, 10 Mar 1999 12:39:14 +0100 In article [EMAIL PROTECTED] you wrote: Synopsis: ./configure --enable-shared is broken [...] Description: ./configure doesn't work with --enable-shared [EMAIL PROTECTED] apache_1.3.4]$ ./configure --enable-shared Configuring for Apache, Version 1.3.4 + using installation path layout: Apache (config.layout) configure:Error: No such module named 'yes' How-To-Repeat: [EMAIL PROTECTED] apache_1.3.4]$ ./configure --enable-shared Configuring for Apache, Version 1.3.4 + using installation path layout: Apache (config.layout) configure:Error: No such module named 'yes' Fix: It's probably something silly in the script. No, it's not something silly in the script. You've not carefully enough read the INSTALL file. The option is clearly documented as --enable-shared=NAME and not --enable-shared. You've to specifiy a module's name. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com
Re: config/3983: __GNUC__ and __GNUC_MINOR__ cpp symbols tested incorrectly
The following reply was made to PR config/3983; it has been noted by GNATS. From: Ralf S. Engelschall [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Subject: Re: config/3983: __GNUC__ and __GNUC_MINOR__ cpp symbols tested incorrectly Date: Wed, 10 Mar 1999 12:36:30 +0100 In article [EMAIL PROTECTED] you wrote: In src/include/ap_config.h, an attempt to test for GNU CC version 2.7 or greater will fail when GCC 3.0 is released Comitted for Apache 1.3.5. Thanks for the patch. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com
Re: documentation/3995: Ambiguity in INSTALL's description of --activate-module flag
The following reply was made to PR documentation/3995; it has been noted by GNATS. From: Ralf S. Engelschall [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Subject: Re: documentation/3995: Ambiguity in INSTALL's description of --activate-module flag Date: Wed, 10 Mar 1999 12:47:32 +0100 In article [EMAIL PROTECTED] you wrote: Synopsis: Ambiguity in INSTALL's description of --activate-module flag [...] Thanks for the two text corrections. They were now comitted for Apache 1.3.5. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com
Re: general/3617: Possible buffer overflow
The following reply was made to PR general/3617; it has been noted by GNATS. From: Ralf S. Engelschall [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Subject: Re: general/3617: Possible buffer overflow Date: Wed, 10 Mar 1999 13:09:58 +0100 In article [EMAIL PROTECTED] you wrote: Synopsis: Possible buffer overflow [...] When reading a config file with line continuation symbols, there is a bug in the calculation of the buffer size. [...] Thanks for catching this bug. It's now fixed for Apache 1.3.5. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com
Re: general/3898: --prefix / --exec-prefix confusion
The following reply was made to PR general/3898; it has been noted by GNATS. From: Ralf S. Engelschall [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Subject: Re: general/3898: --prefix / --exec-prefix confusion Date: Wed, 10 Mar 1999 13:23:37 +0100 In article [EMAIL PROTECTED] you wrote: # uname -a Linux BabelTech.dk 2.1.131 #7 SMP Mon Dec 14 19:08:12 CET 1998 i686 unknown Description: I'm trying to build/install apache in a shareable fashion, where the SW is installed to (in my case) /Packages/Linux-ix86/apache-1.3.4, but is accessed via /usr/local/* - this is managed by using cmu-depot. Usually (mainly other gnu-autoconf kits) it's sufficient to do a configure --prefix=/usr/local ... followed my a make and then a make install prefix=/Packages/Linux-ix86/apache-1.3.4, however the Apache-kit ignores the prefix=.. in the make install .. command, and trying to use configure --prefix=/Packages/Linux-ix86/apache-1.3.4 --exec-prefix=/usr/local results in some of the stuff (mainly the support-tools) going directly to /usr/local, while the rest goes where it's supposed to go. The problem is compounded by the fact that the /usr/local hierarchy is strictly maintained by cmu-depot, which means that stuff that hasn't been added by cmu-depot simply gets deleted. Not a serious problem, but definately an annoying one (to me at least ;-) ) What you're searching for is make install root=, I guess. Look inside the INSTALL file for details. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com
Re: general/3937: Design issues concerning shared memory.
The following reply was made to PR general/3937; it has been noted by GNATS. From: Ralf S. Engelschall [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Subject: Re: general/3937: Design issues concerning shared memory. Date: Wed, 10 Mar 1999 13:29:19 +0100 In article [EMAIL PROTECTED] you wrote: I've just completed a rewrite of the mod_throttle.c code for Apache 1.3.x that allows throttling based on virtual servers. This module requires the use of shared memory in order to properly keep track of the number of bytes_sent for a virtual server. Now there is no pool management for shared memory, that I can see. Also there doesn't not appear to be any module handler called when parent server terminates, which would permit the proper release of shared memory. As a result, shared memory resources appear to leak in that they are consumed and never released when ever the server is stopped and/or restarted. User intervention is then required to issue an ipcrm command. I believe this is a design-flaw in the module handler structure, lack a server termination handler; however, as I've just learned new skills for this project (how to write an Apache module and use of shared memory) it may be a covered by some Apache API and/or a fault in my understanding. Two things: 1. I've already started to integrate a shared memory pool facility into Apache 1.3 by the help of a library I've recently written for this purpose. A first cut for a patch was already posted to the new-httpd mailing list. I hope that in the near future Apache 1.3 provides both heap and shared memory based allocation through it's pool concept. 2. In the meantime, when you use IPC Shared Memory you should do it this way (extracted from my librarys code): if ((fdmem = shmget(IPC_PRIVATE, size, (SHM_R|SHM_W|IPC_CREAT))) == -1) FAIL; if ((area = (void *)shmat(fdmem, NULL, 0)) == ((void *)-1)) FAIL; if (shmctl(fdmem, IPC_STAT, shmbuf) == -1) FAIL; shmbuf.shm_perm.uid = getuid(); shmbuf.shm_perm.gid = getgid(); if (shmctl(fdmem, IPC_SET, shmbuf) == -1) FAIL; if (shmctl(fdmem, IPC_RMID, NULL) == -1) FAIL; The important point is the shmctl() with IPC_RMID _after_ the shmat() but before a corresponding shmdt(). This at least makes sure no shared memory segments are staying around after Apache exists. Perhaps this helps. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com
Re: general/3942: During make install I saw Abort - core several times.
The following reply was made to PR general/3942; it has been noted by GNATS. From: Ralf S. Engelschall [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Subject: Re: general/3942: During make install I saw Abort - core several times. Date: Wed, 10 Mar 1999 13:33:37 +0100 In article [EMAIL PROTECTED] you wrote: lhw0171% uname -a SunOS lhw0171 5.6 Generic_105181-05 sun4u sparc lhw0171% gcc -v Reading specs from /usr/gnu/lib/gcc-lib/sparc-sun-solaris2.6/2.8.1/specs gcc version 2.8.1 Description: === [mktree] === [programs: Installing Apache httpd program and shared objects] ./src/helpers/install.sh -c -s -m 755 ./src/httpd /usr/apache/bin/httpd Abort - core dumped ./src/helpers/install.sh -c -m 644 ./src/support/httpd.8 /usr/apache/man/man8/h\ ttpd.8 === [programs] === [support: Installing Apache support programs and scripts] ./src/helpers/install.sh -c -s -m 755 ./src/support/ab /usr/apache/bin/ab Abort - core dumped ./src/helpers/install.sh -c -m 644 ./src/support/ab.1 /usr/apache/man/man1/ab.1 How-To-Repeat: make install I'm sure our installation procedure isn't broken because it works ;-) Instead I guess some local program the our install.sh script uses is broken on your platform. Try to run it manually and find out which program actually dumps core and contact your OS vendor when it's something like `cp', `chmod', `strip', etc. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com
Re: mod_rewrite/3874: RewriteLock doesn't work for virtual hosts and silently fails
The following reply was made to PR mod_rewrite/3874; it has been noted by GNATS.
From: Ralf S. Engelschall [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: Subject: Re: mod_rewrite/3874: RewriteLock doesn't work for virtual hosts
and silently fails
Date: Wed, 10 Mar 1999 13:54:57 +0100
In article [EMAIL PROTECTED] you wrote:
[...]
The lock file is opened during the init_child() phase and the file pointer is
saved in that server_rec, but that config info isn't propagated to the
virtual
host config. Since the file pointer isn't available, even though locking is
turned on, no locking is done and no warning is given and things break.
How-To-Repeat:
Add a logging line to rewritelock_alloc() like
if (conf-rewritelockfp != -1) {
fd_lock(r, conf-rewritelockfp);
} else if (conf-rewritelockfile) {
ap_log_rerror(APLOG_MARK, APLOG_NOERRNO|APLOG_ALERT, r,
mod_rewrite: Don't have lockfile descriptor, can't
lock);
}
then use RewriteLock and RewriteMap inside and outside of a virtual host
and you'll see that the lockfile fp isn't available through the virtual
host config, so no locking is done.
Fix:
I moved the
rewritelock_open(s, p);
call from the init_child() function to the server for loop in
init_module() where the rewritelog open is as well, and that seems
to have fixed it.
You're right that there might be a problem caused by the fact that the
filedescriptor isn't merged into virtual host. But your solution (moving the
rewritelock_open call to the init_module function) is incorrect, because this
doesn't work on platforms where flock() is used. Because under flock() based
locking the file _has_ to be opened by the child. So the only solution seems
to be to interate in init_child() over the virtual hosts. I'll look at
this...
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
Re: mod_status/3936: 'extendedstatus on' doesn't work
The following reply was made to PR mod_status/3936; it has been noted by GNATS. From: Ralf S. Engelschall [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Subject: Re: mod_status/3936: 'extendedstatus on' doesn't work Date: Wed, 10 Mar 1999 14:01:40 +0100 In article [EMAIL PROTECTED] you wrote: the 'extendedstatus on' parameter doesn't work with the default httpd.conf because it is placed before the 'loadmodule' line. Thanks for the hint. This is now fixed for Apache 1.3.5. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com
Re: os-solaris/3977: build problem related to position independent code (PIC)
The following reply was made to PR os-solaris/3977; it has been noted by GNATS. From: Ralf S. Engelschall [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Subject: Re: os-solaris/3977: build problem related to position independent code (PIC) Date: Wed, 10 Mar 1999 14:37:58 +0100 In article [EMAIL PROTECTED] you wrote: [...] Synopsis: build problem related to position independent code (PIC) [...] We've now switched to -fPIC for Solaris2 and SunOS4 for Apache 1.3.5. Thanks for your feedback. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com
Re: os-aix/3992: Verification startup fail after successful installation.
[In order for any reply to be added to the PR database, ] [you need to include [EMAIL PROTECTED] in the Cc line ] [and leave the subject line UNCHANGED. This is not done] [automatically because of the potential for mail loops. ] [If you do not include this Cc, your reply may be ig- ] [nored unless you are responding to an explicit request ] [from a developer. ] [Reply only with text; DO NOT SEND ATTACHMENTS! ] Synopsis: Verification startup fail after successful installation. State-Changed-From-To: open-closed State-Changed-By: coar State-Changed-When: Wed Mar 10 09:54:56 PST 1999 State-Changed-Why: The current code is correct; it is the AIX C compiler that is generating bad code. This has been reported numerous times and is in the FAQ; see URL http://www.apache.org/docs/misc/FAQ.html#aixccbug. Category-Changed-From-To: general-os-aix Category-Changed-By: coar Category-Changed-When: Wed Mar 10 09:54:56 PST 1999
re: general/3872: util_script.c doubles up Set-Cookie headers from r-err_headers_out
The following reply was made to PR general/3872; it has been noted by GNATS.
From: Dean Gaudet [EMAIL PROTECTED]
To: Jeff Lewis [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: re: general/3872: util_script.c doubles up Set-Cookie headers from
r-err_headers_out
Date: Wed, 10 Mar 1999 10:05:48 -0800 (PST)
Commenting out the ap_table_do line would pose troubles if there were two
Set-Cookie headers already in err_headers_out... I'm pretty sure the patch
below is the right way to fix it. Can you test to make sure it works for
you?
Thanks
Dean
Index: main/util_script.c
===
RCS file: /home/cvs/apache-1.3/src/main/util_script.c,v
retrieving revision 1.138
diff -u -r1.138 util_script.c
--- util_script.c 1999/02/05 00:37:48 1.138
+++ util_script.c 1999/03/10 18:04:53
@@ -496,6 +496,8 @@
ap_overlap_tables(r-err_headers_out, merge,
AP_OVERLAP_TABLES_MERGE);
if (!ap_is_empty_table(cookie_table)) {
+ /* the cookies have already been copied to the cookie_table */
+ ap_table_unset(r-err_headers_out, Set-Cookie);
r-err_headers_out = ap_overlay_tables(r-pool,
r-err_headers_out, cookie_table);
}
Re: general/3872: util_script.c doubles up Set-Cookie headers from r-err_headers_out
[In order for any reply to be added to the PR database, ] [you need to include [EMAIL PROTECTED] in the Cc line ] [and leave the subject line UNCHANGED. This is not done] [automatically because of the potential for mail loops. ] [If you do not include this Cc, your reply may be ig- ] [nored unless you are responding to an explicit request ] [from a developer. ] [Reply only with text; DO NOT SEND ATTACHMENTS! ] Synopsis: util_script.c doubles up Set-Cookie headers from r-err_headers_out State-Changed-From-To: open-analyzed State-Changed-By: dgaudet State-Changed-When: Wed Mar 10 10:11:41 PST 1999 State-Changed-Why: yup it's a bug -- the suggested fix isn't quite right though, sent a patch separately (and committed it, what the heck)
mod_proxy/4028: Getting ap_bgets() - proxy receive - Error reading from remote server server
Number: 4028 Category: mod_proxy Synopsis: Getting ap_bgets() - proxy receive - Error reading from remote server server Confidential: no Severity: serious Priority: medium Responsible:apache State: open Class: sw-bug Submitter-Id: apache Arrival-Date: Wed Mar 10 11:30:01 PST 1999 Last-Modified: Originator: [EMAIL PROTECTED] Organization: apache Release:1.3.3 and 1.3.4 Environment: Solaris 2.5.1 (103640-24) gcc 2.7.2.1 Description: When trying to view RTSP (ala RealNetworks) through the proxy, we recieve these errors in the log file. This then causes the client to timeout and not to get the data. How-To-Repeat: rtsp://207.239.133.66/g2audio.rm Fix: Use the old CERN proxy. Audit-Trail: Unformatted: [In order for any reply to be added to the PR database, ] [you need to include [EMAIL PROTECTED] in the Cc line ] [and leave the subject line UNCHANGED. This is not done] [automatically because of the potential for mail loops. ] [If you do not include this Cc, your reply may be ig- ] [nored unless you are responding to an explicit request ] [from a developer. ] [Reply only with text; DO NOT SEND ATTACHMENTS! ]
suexec/4030: Cannot make suexec under Solaris 2.6
Number: 4030 Category: suexec Synopsis: Cannot make suexec under Solaris 2.6 Confidential: no Severity: non-critical Priority: medium Responsible:apache State: open Class: sw-bug Submitter-Id: apache Arrival-Date: Wed Mar 10 13:30:01 PST 1999 Last-Modified: Originator: [EMAIL PROTECTED] Organization: apache Release:1.3.4 Environment: Sun Ultra-1, Solaris 2.6 (aka SunOS 5.6) and its make, gcc 2.8.1 Description: After configuring apache 1.3.4 for suexec, make stops when trying to build suexec.o from suexec.c. This is due to a simple typo in the top-level Makefile. The source code cannot be found and make exits with something like: - screen output BEGIN -- gcc -c -I../os/unix -I../include -DSOLARIS2=260 \ -DHTTPD_USER=\www\ \ -DUID_MIN=100 \ -DGID_MIN=100 \ -DUSERDIR_SUFFIX=\public_html\ \ -DLOG_EXEC=\/usr/local/apache/logs/suexec_log\ \ -DDOC_ROOT=\/usr/local/apache/htdocs\ \ -DSAFE_PATH=\/usr/local/bin:/usr/bin\ \ suexec.c gcc: suexec.c: No such file or directory gcc: No input files *** Error code 1 make: Fatal error: Command failed for target `suexec.o' Current working directory /tmp/apache_1.3.4/src/support *** Error code 1 make: Fatal error: Command failed for target `build-support' Current working directory /tmp/apache_1.3.4 *** Error code 1 make: Fatal error: Command failed for target `build' - screen output END -- The problem is the line -DSAFE_PATH=\/usr/local/bin:/usr/bin\ \ suexec.c ^^^ How-To-Repeat: I think, anyone who tries to build apache 1.3.4 with suexec gets this error. I did exactly what is described in the README.configure example (line 98ff). Fix: I fixed the problem by editing the Makefile manually. Here the patch patch BEGIN 181c181,182 -DSAFE_PATH=\$(suexec_safepath)\' \ --- -DSAFE_PATH=\$(suexec_safepath)\ \ ' \ patch BEGIN A better way would be to correct the mistake in the templates/configure script, but I lack the knowledge and time to do so. Audit-Trail: Unformatted: [In order for any reply to be added to the PR database, ] [you need to include [EMAIL PROTECTED] in the Cc line ] [and leave the subject line UNCHANGED. This is not done] [automatically because of the potential for mail loops. ] [If you do not include this Cc, your reply may be ig- ] [nored unless you are responding to an explicit request ] [from a developer. ] [Reply only with text; DO NOT SEND ATTACHMENTS! ]
config/4032: Serving a business site
Number: 4032 Category: config Synopsis: Serving a business site Confidential: no Severity: serious Priority: medium Responsible:apache State: open Class: support Submitter-Id: apache Arrival-Date: Wed Mar 10 14:10:00 PST 1999 Last-Modified: Originator: [EMAIL PROTECTED] Organization: apache Release:1.3.4 Environment: Win98, what is a patchlevel? and what do you mean what compiler? Description: I have started a business called ViperSoft Inc. and wish to have a website. I have registered and payed for www.vipersoft.org, and wish to host it on my own with Apache. That is all, and I have followed the manual and FAQs, but I still can't seem to get it to work! Can someone please guide me through the process of just getting the site UP? How-To-Repeat: Fix: no Audit-Trail: Unformatted: [In order for any reply to be added to the PR database, ] [you need to include [EMAIL PROTECTED] in the Cc line ] [and leave the subject line UNCHANGED. This is not done] [automatically because of the potential for mail loops. ] [If you do not include this Cc, your reply may be ig- ] [nored unless you are responding to an explicit request ] [from a developer. ] [Reply only with text; DO NOT SEND ATTACHMENTS! ]
Re: config/4032: Serving a business site
[In order for any reply to be added to the PR database, ] [you need to include [EMAIL PROTECTED] in the Cc line ] [and leave the subject line UNCHANGED. This is not done] [automatically because of the potential for mail loops. ] [If you do not include this Cc, your reply may be ig- ] [nored unless you are responding to an explicit request ] [from a developer. ] [Reply only with text; DO NOT SEND ATTACHMENTS! ] Synopsis: Serving a business site State-Changed-From-To: open-closed State-Changed-By: marc State-Changed-When: Wed Mar 10 14:16:32 PST 1999 State-Changed-Why: No. This is for reporting bugs, not for trying to understand what a web server is and how it works.
general/4033: HTTP/0.9 requests yield invalid response
Number: 4033 Category: general Synopsis: HTTP/0.9 requests yield invalid response Confidential: no Severity: non-critical Priority: medium Responsible:apache State: open Class: sw-bug Submitter-Id: apache Arrival-Date: Wed Mar 10 15:20:00 PST 1999 Last-Modified: Originator: [EMAIL PROTECTED] Organization: apache Release:1.3.[34] Environment: doesn't matter, it's a problem with the resquest parser/response generator: FreeBSD sapphire.edcenter.lane.edu 3.0-RELEASE FreeBSD 3.0-RELEASE #4: Tue Jan 5 14:14:55 PST 1999 [EMAIL PROTECTED]:/usr/src/sys/compile/sapphire i386 Description: if you generate a HTTP request using the HTTP/0.9 protocol it will send a Full HTTP/1.1 response instead of the simple response as mandated by rfc1945... the fix is to return a simple request when you recieve a HTTP version of 0.9. How-To-Repeat: telnet somehostrunningapache 80 GET /somefile HTTP/0.9 here is where it should dump then entity body but instead it returns a full response Fix: I haven't looked at the code, but simply don't send the headers when you recieve a HTTP/0.9 request. Audit-Trail: Unformatted: [In order for any reply to be added to the PR database, ] [you need to include [EMAIL PROTECTED] in the Cc line ] [and leave the subject line UNCHANGED. This is not done] [automatically because of the potential for mail loops. ] [If you do not include this Cc, your reply may be ig- ] [nored unless you are responding to an explicit request ] [from a developer. ] [Reply only with text; DO NOT SEND ATTACHMENTS! ]
Re: general/4033: HTTP/0.9 requests yield invalid response
[In order for any reply to be added to the PR database, ] [you need to include [EMAIL PROTECTED] in the Cc line ] [and leave the subject line UNCHANGED. This is not done] [automatically because of the potential for mail loops. ] [If you do not include this Cc, your reply may be ig- ] [nored unless you are responding to an explicit request ] [from a developer. ] [Reply only with text; DO NOT SEND ATTACHMENTS! ] Synopsis: HTTP/0.9 requests yield invalid response State-Changed-From-To: open-feedback State-Changed-By: marc State-Changed-When: Wed Mar 10 15:21:51 PST 1999 State-Changed-Why: Erm... a HTTP/0.9 request, by definition, doesn't have a version number in the request but is just in the form GET /foo. Do you have some reason for thinking that specifying it should work?
Re: suexec/4030: Cannot make suexec under Solaris 2.6
Hi, [EMAIL PROTECTED] schrieb: Thank you very much for your problem report. It has the internal identification `suexec/4030'. The individual assigned to look at your report is: apache. Category: suexec Responsible:apache Synopsis: Cannot make suexec under Solaris 2.6 Arrival-Date: Wed Mar 10 13:30:01 PST 1999 Since I'm not running Solaris on any of the systems I have access to, I guess, I'm not the one who'd sent a problem report. This assumption is not proven but at least hardened by the fact, that I can't remember neither the situation prior to the fault nor the fault itself. In this case, you should try to reach the other guy who'd made this experience in his personal reality. In any other case, try 42 as the most probable answer to any of your upcoming questions belonging to this concern. This is just a proposal, but better than just hot air, which is the stuff all other answers you could request from me would consist of - as far as they belong to the category mentioned above. Ok, guys, it's about 0:45h AM and, re-reading my reply to your mail, it's definitely time to go to bed. Have a nice day :-) A bientôt Peter
Re: suexec/4030: Cannot make suexec under Solaris 2.6
The following reply was made to PR suexec/4030; it has been noted by GNATS. From: Peter Franken [EMAIL PROTECTED] To: [EMAIL PROTECTED], apache-bugdb@apache.org Cc: Subject: Re: suexec/4030: Cannot make suexec under Solaris 2.6 Date: Thu, 11 Mar 1999 00:42:13 +0100 Hi, [EMAIL PROTECTED] schrieb: Thank you very much for your problem report. It has the internal identification `suexec/4030'. The individual assigned to look at your report is: apache. Category: suexec Responsible:apache Synopsis: Cannot make suexec under Solaris 2.6 Arrival-Date: Wed Mar 10 13:30:01 PST 1999 Since I'm not running Solaris on any of the systems I have access to, I guess, I'm not the one who'd sent a problem report. This assumption is not proven but at least hardened by the fact, that I can't remember neither the situation prior to the fault no r the fault itself. In this case, you should try to reach the other guy who'd made this experience in his personal reality. In any other case, try 42 as the most probable answer to any of your upcoming questions belonging to this concern. This is just a proposal, but better than just hot air, which is the stuff all other answers you could request from me would consist of - as far as they belong to the category mentioned above. Ok, guys, it's about 0:45h AM and, re-reading my reply to your mail, it's definitely time to go to bed. Have a nice day :-) A bientôt Peter
