DO NOT REPLY [Bug 8633] New: - [RFE] Add application/x-rar-compressed rar to conf/mime.types

2002-04-30 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8633

[RFE] Add application/x-rar-compressed  rar to conf/mime.types

   Summary: [RFE] Add application/x-rar-compressed rar to
conf/mime.types
   Product: Apache httpd-1.3
   Version: 1.3.23
  Platform: All
OS/Version: All
Status: NEW
  Severity: Minor
  Priority: Other
 Component: Other
AssignedTo: bugs@httpd.apache.org
ReportedBy: [EMAIL PROTECTED]


*.rar files should be sent with the Content-type of
application/x-rar-compressed.  They are currently sent as text/plain.  I suggest
adding the line:

application/x-rar-compressed
rar

to conf/mime.types.


DO NOT REPLY [Bug 8636] New: - https proxy

2002-04-30 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8636

https proxy

   Summary: https proxy
   Product: Apache httpd-1.3
   Version: 1.3.24
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: mod_proxy
AssignedTo: bugs@httpd.apache.org
ReportedBy: [EMAIL PROTECTED]


I access Lotus Domino server via apache SSL proxy (secure proxy), 
configuration: 
ServerName apache
ProxyPass / http://domino/
ProxyPassReverse http://apache https://apache
SSLXXX 

flow chart as below:
   httpshttp
   MS IE(6.0) ===> apache + mod_proxy + mod_ssl => Lotus Domino Server

I access https://apache/mail/test.nsf url, then Domino return HTTP header 
Location: http://apache/mail/tes.nsf, apache return 404 not founded.

These information is captured by my network monitor.


DO NOT REPLY [Bug 8643] New: - Online docs have incorrect link

2002-04-30 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8643

Online docs have incorrect link

   Summary: Online docs have incorrect link
   Product: Apache httpd-2.0
   Version: 2.0.35
  Platform: All
OS/Version: All
Status: NEW
  Severity: Minor
  Priority: Other
 Component: Documentation
AssignedTo: bugs@httpd.apache.org
ReportedBy: [EMAIL PROTECTED]


In the online manual, on this page:

 http://httpd.apache.org/docs-2.0/server-
wide.html

Clicking on the link for "CoreDumpDirectory", under the "File Locations" 
section takes you to a page that has no informaiton about "CoreDumpDirectory".


DO NOT REPLY [Bug 7642] - getnameinfo() not found when lookup on 127.0.0.1 fails

2002-04-30 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7642

getnameinfo() not found when lookup on 127.0.0.1 fails

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2002-04-30 11:04 ---
A fix for the inability to find getnameinfo() will be in the next Apache 
release after 2.0.36.  A fix for mod_unique_id requiring an IPv4 address 
will be in Apache 2.0.36.  Both of these fixes are in current CVS.


DO NOT REPLY [Bug 8659] New: - httpd fails to start if a (module's) log file isnt touch-ed

2002-04-30 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8659

httpd fails to start if a (module's) log file isnt touch-ed

   Summary: httpd fails to start if a (module's) log file isnt
touch-ed
   Product: Apache httpd-2.0
   Version: 2.0.35
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Other Modules
AssignedTo: bugs@httpd.apache.org
ReportedBy: [EMAIL PROTECTED]


I've tried to include mod_gzip for httpd-2.0.xx.
It had debuging #define turned on by default, so i commented it out.  
When i tried to fire httpd back up after recompiling i got "Configuration
Failed" in the error log and it failed to start as well.
I explored the problem a bit further and noticed it has some thing to do
with a log file fopen()ing. 
If a certain function returns right in beginning, httpd wont start up.
But if the same function fopens a file, closes it back and returns
right after that, httpd runs normally.  

working version: http://www.tgpsoftware.com/mod_gzip.c
nonworking version: http://www.tgpsoftware.com/mod_gzip2.c

the only difference is in line# 374:  return;

It got me a bit confused. Can a module cause this?


DO NOT REPLY [Bug 8659] - httpd fails to start if a (module's) log file isnt touch-ed

2002-04-30 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8659

httpd fails to start if a (module's) log file isnt touch-ed





--- Additional Comments From [EMAIL PROTECTED]  2002-04-30 14:21 ---
Your link http://www.tgpsoftware.com/mod_gzip2.c is invalid.

Please paste the offensive function (the non-working version, of course)
so we can comment.


DO NOT REPLY [Bug 8643] - Online docs have incorrect link

2002-04-30 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8643

Online docs have incorrect link

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2002-04-30 14:22 ---
The links are now fixed on httpd.apache.org and in the library, so
a future release of Apache will have the fixes.

Thanks for your report, and thanks for using Apache!


DO NOT REPLY [Bug 8633] - [RFE] Add application/x-rar-compressed rar to conf/mime.types

2002-04-30 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8633

[RFE] Add application/x-rar-compressed  rar to conf/mime.types

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX



--- Additional Comments From [EMAIL PROTECTED]  2002-04-30 14:26 ---
Our policy for mime.types is listed here:
http://httpd.apache.org/docs-2.0/mod/mod_mime.html

Essentially, it says that we'll only add IANA registered types.
This type is not registered.  Please let us know if it does
become a registered type and we will consider adding it.

Thanks.


DO NOT REPLY [Bug 8572] - This URL is too long for mod_ssl to have as the name of a website

2002-04-30 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8572

This URL is too long for mod_ssl to have as the name of a website





--- Additional Comments From [EMAIL PROTECTED]  2002-04-30 14:50 ---
If I look at the source code for mod_ssl 2.8.8-1.3.24 it does look like the md5 
change is in ssl_engine_kernel.c.  This ssl_engine_kernel.c was last changed on 
March 27, 2002 which is over a month ago.  So I'll accept your assertion that 
the fix will be in Apache 2.0.36.  Thanks!


DO NOT REPLY [Bug 8636] - https proxy

2002-04-30 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8636

https proxy

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2002-04-30 14:52 ---
I'm having a difficult time figuring out where you got that configuration
for ProxyPassReverse.  It seems to me that you want
ProxyPassReverse / http://domino/

In any case, this problem would probably be better addressed in a user support
forum like
http://httpd.apache.org/userslist.html
unless you can confirm that you have found a bug in Apache rather than a
configuartion problem.

Thanks.


DO NOT REPLY [Bug 8659] - httpd fails to start if a (module's) log file isnt touch-ed

2002-04-30 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8659

httpd fails to start if a (module's) log file isnt touch-ed





--- Additional Comments From [EMAIL PROTECTED]  2002-04-30 14:56 ---
We are in middle of a DNS update. URLs should work now. Sorry about that.
Here is the code:

--- snip ---

void mod_gzip_printf( const char *fmt, ... )
{

 int   l;
 char *p1;
 FILE *log;

 va_list ap;

 char logname[256];
 char log_line[4096];

 #ifdef WIN32
 long pid = GetCurrentProcessId();
 #else
 long pid = (long) getpid();
 #endif
 #ifdef WIN32
 sprintf( logname, "c:\\temp\\t%ld.log",(long)pid);
 #else
 sprintf( logname, "/tmp/t%ld.log",(long)pid);
 #endif

 return;  // line 374

// it fails if it returns before opening the file below


 log = fopen( logname,"a" );

 if ( !log ) 
 {
   return; 
 }
 else
 {
   fclose(log);
   return;
 }


.
.
.
.
--- snip ---


DO NOT REPLY [Bug 8659] - httpd fails to start if a (module's) log file isnt touch-ed

2002-04-30 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8659

httpd fails to start if a (module's) log file isnt touch-ed

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2002-04-30 14:58 ---
The link works for me, but I can't figure out why you are reporting a problem
with mod_gzip here.  mod_gzip is a third-party module that we don't have 
anything to do with.  Please report this to the mod_gzip authors
(or try the mod_deflate module, which does come with Apache 2 and includes
similar functionality).


DO NOT REPLY [Bug 8663] New: - ServerSignature can not be turned off

2002-04-30 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8663

ServerSignature can not be turned off

   Summary: ServerSignature can not be turned off
   Product: Apache httpd-2.0
   Version: 2.0.35
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Core
AssignedTo: bugs@httpd.apache.org
ReportedBy: [EMAIL PROTECTED]


ServerSignature can not be turned off. I use Apache 2.0.35 on Windows 2000 
Server (german version) with Service Pack 2. It does not matter if the 
ServerSignature is On, Off or EMail, the server returns the full information in 
any case within the server-generated error document (e.g. Object not found, 
Error 404).


DO NOT REPLY [Bug 8659] - httpd fails to start if a (module's) log file isnt touch-ed

2002-04-30 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8659

httpd fails to start if a (module's) log file isnt touch-ed





--- Additional Comments From [EMAIL PROTECTED]  2002-04-30 15:35 ---

  I see nothing in that snippet that indicates an API issue with APR or httpd.
  Looks like a logic error elsewhere.  This code isn't APR'ized, so that can't
  be the issue, and you aren't even dealing with an Apache log.

  I concur with Joshua here, this report is irrelevant.


DO NOT REPLY [Bug 8663] - ServerSignature can not be turned off

2002-04-30 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8663

ServerSignature can not be turned off

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WORKSFORME



--- Additional Comments From [EMAIL PROTECTED]  2002-04-30 15:39 ---
I just confirmed that this "works for me".

I'm almost sure that your problem is that you aren't using the "internal" error
messages.  Rather, you are using the Multilingual custom error reponses that
come bundled with httpd 2.0 and are turned on by default.  Search your 
httpd.conf
for ErrorDocument and you will see instructions on how to customize these 
messages
(or just turn them off by commenting them out).

It would be nice if these messages could respect ServerSignature, but I don't
see any way for that to work.


DO NOT REPLY [Bug 8572] - This URL is too long for mod_ssl to have as the name of a website

2002-04-30 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8572

This URL is too long for mod_ssl to have as the name of a website





--- Additional Comments From [EMAIL PROTECTED]  2002-04-30 16:31 ---
Can you give me a specific line number?  I still can't find the change you're 
talking 
about in modssl 2.8.8 to be sure it's in Apache 2.0.36. 
Thanks!


DO NOT REPLY [Bug 8431] - AddHandler/Action not-found when file does not exist

2002-04-30 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8431

AddHandler/Action not-found when file does not exist

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||REMIND



--- Additional Comments From [EMAIL PROTECTED]  2002-04-30 16:36 ---
Thanks, Joshua!

now instead "ScriptAlias" and "Action" I use:

ScriptAliasMatch (.*)(\.fwx|\.prg) "C:/.../Apache2/cgi-bin/foxweb.exe$1.$2"

it's working (I'm only not sure about situaion, when ".fwx" or ".prg" can be 
part of parameters - it will be also replaced?)

but for some reson line
ScriptAliasMatch (.*)(\.fwx|\.prg) "/cgi-bin/foxweb.exe$1.$2"
is not working regardles alias "/cgi-bin/" is defined


> AddHandler is *not* the correct way to accomplish that.
I disagree
I think the AddHandler *is* the best solution for process files with specialy 
defined extensions


thanks again

vadim


DO NOT REPLY [Bug 8572] - This URL is too long for mod_ssl to have as the name of a website

2002-04-30 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8572

This URL is too long for mod_ssl to have as the name of a website





--- Additional Comments From [EMAIL PROTECTED]  2002-04-30 16:39 ---
AHA!  Found it.  And it's not in yet for some strange reason.  Hmph.  Okay, 
well, I'll get 
the change committed today and *hopefully* it will be in 2.0.36, but the 
schedule is 
pretty tight on that.


DO NOT REPLY [Bug 8431] - AddHandler/Action not-found when file does not exist

2002-04-30 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8431

AddHandler/Action not-found when file does not exist

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|REMIND  |



--- Additional Comments From [EMAIL PROTECTED]  2002-04-30 16:49 ---
Reopening to change Resolution.


DO NOT REPLY [Bug 8431] - AddHandler/Action not-found when file does not exist

2002-04-30 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8431

AddHandler/Action not-found when file does not exist

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||WONTFIX



--- Additional Comments From [EMAIL PROTECTED]  2002-04-30 16:52 ---
If you'd like to discuss your configuration problem, please joing the apache
users mailing list.

Regarding
> I think the AddHandler *is* the best solution for process files with specialy 
> defined extensions
AddHandler *does* process files with specially defined extensions.  What it
doesn't do is process URLs with special extensions that just happen to map
to a file when processed thorugh some cgi script.  Apache has no knowledge
that the CGI script is going to map the URL back to a file.

In other words, if the file isn't in the webspace, AddHandler is not the
way to deal with it.

Thanks.


DO NOT REPLY [Bug 8572] - This URL is too long for mod_ssl to have as the name of a website

2002-04-30 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8572

This URL is too long for mod_ssl to have as the name of a website

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2002-04-30 17:10 ---
So apparently this is not NEW functionality in modssl 2.8.8, which is why I 
didn't find  
it before.  It's functionality that was removed between Apache 2.0.33 and 
2.0.34 as a  
"minor performance improvement", obviously unaware of this unintended 
side-effect.  The  
following patch reverts to the MD5 behavior.  That change has been reverted.  
Thanks for 
using Apache!


DO NOT REPLY [Bug 8572] - This URL is too long for mod_ssl to have as the name of a website

2002-04-30 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8572

This URL is too long for mod_ssl to have as the name of a website





--- Additional Comments From [EMAIL PROTECTED]  2002-04-30 17:12 ---
===  
RCS file: /home/cvspublic/httpd-2.0/modules/ssl/mod_ssl.c,v  
retrieving revision 1.63  
retrieving revision 1.64  
diff -u -r1.63 -r1.64  
--- httpd-2.0/modules/ssl/mod_ssl.c 2002/04/07 03:37:35 1.63  
+++ httpd-2.0/modules/ssl/mod_ssl.c 2002/04/30 17:10:12 1.64  
@@ -279,6 +279,7 @@  
 SSLSrvConfigRec *sc = mySrvConfig(c->base_server);  
 SSL *ssl;  
 SSLConnRec *sslconn = myConnConfig(c);  
+char *vhost_md5;  
 modssl_ctx_t *mctx;  
  
 /*  
@@ -334,12 +335,13 @@  
 return DECLINED; /* XXX */  
 }  
  
-if (!SSL_set_session_id_context(ssl,  
-(unsigned char *)sc->vhost_id,  
-sc->vhost_id_len))  
+vhost_md5 = ap_md5_binary(c->pool, sc->vhost_id, sc->vhost_id_len);  
+  
+if (!SSL_set_session_id_context(ssl, (unsigned char *)vhost_md5,  
+MD5_DIGESTSIZE*2))  
 {  
 ssl_log(c->base_server, SSL_LOG_ERROR|SSL_ADD_SSLERR,  
-"Unable to set session id context to `%s'", sc->vhost_id);  
+"Unable to set session id context to `%s'", vhost_md5);  
  
 c->aborted = 1;


DO NOT REPLY [Bug 8671] New: - Stuck httpd processes on Solaris 8 generate high load

2002-04-30 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8671

Stuck httpd processes on Solaris 8 generate high load

   Summary: Stuck httpd processes on Solaris 8 generate high load
   Product: Apache httpd-2.0
   Version: 2.0.35
  Platform: Sun
   URL: http://www.cookwareinc.com
OS/Version: Solaris
Status: NEW
  Severity: Critical
  Priority: Other
 Component: All
AssignedTo: bugs@httpd.apache.org
ReportedBy: [EMAIL PROTECTED]


We just upgraded to Solaris 8 and Apache 2.0.35 and are experiencing a 
problem we havn't seen before.  The compile is standard with the 
exception that we've included the SSL module... but this does not appear 
to be related to secure server requests.

On a daily basis we are seeing a single httpd process refuse to die. It 
generates a load of 1.0 for itself only, and runs forever stuck.  We can KILL 
-9 the process, and everything else runs fine... until the next one happens.

We have noted that if we don't kill it (e.g., we don't notice it right away), 
soon thereafter more are affected (we had about 14 of them stuck 
yesterday, generating a CPU load of 14.0).

We're on a DUAL PROCESSOR Sun ULTRA (Creator 3D series) - if that 
helps any.

One additional note... I put special logging in that logs both the PID and 
the URL, to see if this happens only on a particular virtual host or site we 
run - it doesn't appear to... just as it doesn't appear to be related to secure 
server (SSL) functioning.


DO NOT REPLY [Bug 8672] New: - mod_proxy HTTP/1.1 delay

2002-04-30 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8672

mod_proxy HTTP/1.1 delay

   Summary: mod_proxy HTTP/1.1 delay
   Product: Apache httpd-1.3
   Version: 1.3.24
  Platform: Sun
OS/Version: Solaris
Status: NEW
  Severity: Normal
  Priority: Other
 Component: mod_proxy
AssignedTo: bugs@httpd.apache.org
ReportedBy: [EMAIL PROTECTED]


In our environment, we use apache as a proxy for our backend weblogic 5.1 
servers.

I just recently upgraded our apache server in our QA environment to apache
1.3.24 because I noticed that there were quite a few enhancements to mod_proxy.
 Unfortunately, apache 1.3.24 seems to be very very slow when dealing with
http/1.1 proxy requests.

It looks like what is happening is that the client makes an HTTP/1.1 request to
the apache server.  The apache server then sends a HTTP/1.1 request to the
weblogic server.  It processes the request, then sends back it's reply, along
with a Connection: Keep-Alive header.  The apache server then keeps that
connection open, but doesn't send any further requests along that connection,
and doesn't send the reply to the client.  Eventually, the weblogic server kills
the idle connection, and apache sends the reply back to the client.


Is this the proper way for an http/1.1 proxy to work?


DO NOT REPLY [Bug 8431] - AddHandler/Action not-found when file does not exist

2002-04-30 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8431

AddHandler/Action not-found when file does not exist





--- Additional Comments From [EMAIL PROTECTED]  2002-04-30 18:10 ---
You are right,
but:
--  Apache 1.3 was not check exist file or not if it passed to handler (let's 
handler care about this) - and that was very useful and clear
--  in 1.3 alias /cgi-bin/ was suxessfuly substituted - probably this is does 
not working in 2.0, because RegExpr use another logic and does not allow to 
process common stuf for ScriptAliasMatch - again previous style was more clear 
--  in 2.0:
>> if I create empty(!) file c:\web\dir\script.fwx, so 
>> h:\...\foxweb\dir\script.fwx is processed successfuly
we have funy situation: check existing of one file, but run another

so, I still thinking - this is a B-U-U-U-G! (sorry, out of control)

thanks,
vadim


DO NOT REPLY [Bug 8141] - Weird DirectoryIndex/XBitHack problem

2002-04-30 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8141

Weird DirectoryIndex/XBitHack problem





--- Additional Comments From [EMAIL PROTECTED]  2002-04-30 18:14 ---
I believe this could be a similar bug to Bug 7966
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7966

At least the bit about your includes in your index.html
files not working well unless you specify url/index.html,
that seems to be the same problem (and it's already been
fixed)


DO NOT REPLY [Bug 8671] - Stuck httpd processes on Solaris 8 generate high load

2002-04-30 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8671

Stuck httpd processes on Solaris 8 generate high load

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE



--- Additional Comments From [EMAIL PROTECTED]  2002-04-30 18:19 ---
This looks suspiciously like PR 8165 - which has already been resolved in CVS.

Please read that PR for more information and its resolution.  It should be
included in the forthcoming Apache 2.0.36.

Thanks for using Apache!

*** This bug has been marked as a duplicate of 8165 ***


DO NOT REPLY [Bug 8165] - weird: 100% cpu usage after a simple single ssl connection

2002-04-30 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8165

weird: 100% cpu usage after a simple single ssl connection

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]



--- Additional Comments From [EMAIL PROTECTED]  2002-04-30 18:19 ---
*** Bug 8671 has been marked as a duplicate of this bug. ***


DO NOT REPLY [Bug 8141] - Weird DirectoryIndex/XBitHack problem

2002-04-30 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8141

Weird DirectoryIndex/XBitHack problem

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE



--- Additional Comments From [EMAIL PROTECTED]  2002-04-30 18:21 ---
Yeah, I agree - this looks like 7966 which has already been resolved.  Please
review that PR for the fixes.

Thanks for using Apache!

*** This bug has been marked as a duplicate of 7966 ***


DO NOT REPLY [Bug 7966] - Wrong Content-Length when SSI used as DirectoryIndex

2002-04-30 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7966

Wrong Content-Length when SSI used as DirectoryIndex

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]



--- Additional Comments From [EMAIL PROTECTED]  2002-04-30 18:21 ---
*** Bug 8141 has been marked as a duplicate of this bug. ***


DO NOT REPLY [Bug 8431] - AddHandler/Action not-found when file does not exist

2002-04-30 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8431

AddHandler/Action not-found when file does not exist





--- Additional Comments From [EMAIL PROTECTED]  2002-04-30 18:24 ---

1. The behavior in 1.3 was wrong.  AddHandler maps *files* to handlers.  If
the file does not exist in the apache webspace, then there is nothing to
map.  I am fairly confident that the new behavior is clearer and more
consistent.  (The old behavior had various bad side-effects like handlers
needing to deal with 404 errors on their own, rather than using the internal
404 handler.)

2. I think you misunderstand how ScriptAlias works.  That should be taken
up on the users mailing list, not here.

3. I don't see any problem or inconsistency with the fact that an empty file
works.  The handler can deal with the empty file however it wants.  The fact
that your handler completely ignores the file and finds a new file to serve
from outside the webspace is a design decision on your part.

In any case, I think we are beyond the scope of the bug database.  If you'd
like to argue about the design decision, dev@httpd.apache.org is the place to
go.  If you want further configuration help, users@httpd.apache.org is the
place.

Thanks for using Apache!


DO NOT REPLY [Bug 8424] - IPV6 and IPV4 bind

2002-04-30 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8424

IPV6 and IPV4 bind





--- Additional Comments From [EMAIL PROTECTED]  2002-04-30 18:39 ---
On NetBSD you'll need to add an additional listen statement like the one
shown below in order to accept IPv4 connections too:

  Listen 0.0.0.0:80


DO NOT REPLY [Bug 8673] New: - mod_proxy dropping content length header

2002-04-30 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8673

mod_proxy dropping content length header

   Summary: mod_proxy dropping content length header
   Product: Apache httpd-2.0
   Version: 2.0.35
  Platform: All
OS/Version: All
Status: NEW
  Severity: Major
  Priority: Other
 Component: mod_proxy
AssignedTo: bugs@httpd.apache.org
ReportedBy: [EMAIL PROTECTED]


We are using mod_proxy to proxy pdf documents on an internal web server.

The mod_proxy with 2.x is not returning the content-length of the pdf.
Using a 1.3 version of mod_proxy, to the same webserver, will return a content-
length header.

Below is the headers for a 1.3 and a 2.0 apache version.  Notice that the 2.x 
apache does not return a content length header, while the 1.3 does.

Request to a 2.0.35 apache
GET /msds2/documents/190252.pdf  HTTP/1.1
Accept: text/html, text/css, text/xml, text/plain, application/csv, 
application/pdf, application/msword, application/vnd.ms-excel, application/x-
vbscript, application/x-www-form-urlencoded, application/x-javascript
Accept-Language: en_us
Host: acadv04.ami.alcoa.com:16888
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)
Connection: Close

Response:
HTTP/1.1 200 OK
Date: Tue, 30 Apr 2002 16:24:38 GMT
Server: Microsoft-IIS/5.0
Content-Type: application/pdf
Accept-Ranges: bytes
Last-Modified: Tue, 31 Oct 2000 04:00:00 GMT
ETag: "0e012aef42c01:7e8"
Connection: close
Transfer-Encoding: chunked

81f5
%PDF-1.3
...etc...


Request to a 1.3 apache
 
GET /msds2/documents/190252.pdf HTTP/1.1
Accept: text/html, text/css, text/xml, text/plain, application/csv, 
application/pdf, application/msword, application/vnd.ms-excel, application/x-
vbscript, application/x-www-form-urlencoded, application/x-javascript
Accept-Language: en_us
Host: acadv04.ami.alcoa.com:7380
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)
Connection: Close

Response:
HTTP/1.0 200 OK
Server: Microsoft-IIS/5.0
Date: Tue, 30 Apr 2002 16:08:14 GMT
Content-Type: application/pdf
Accept-Ranges: bytes
Last-Modified: Tue, 31 Oct 2000 04:00:00 GMT
ETag: "0e012aef42c01:7e8"
Content-Length: 84348

%PDF-1.3
...etc...


DO NOT REPLY [Bug 8673] - mod_proxy dropping content length header

2002-04-30 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8673

mod_proxy dropping content length header

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2002-04-30 18:43 ---
This doesn't look like a bug to me.  The 2.0 proxy is sending an HTTP/1.1 
response
using chunked encoding.  There is no content-length header needed when chunked
encoding is used.

Thanks for using Apache!


DO NOT REPLY [Bug 8306] - Apache Parent Process Pauses

2002-04-30 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8306

Apache Parent Process Pauses





--- Additional Comments From [EMAIL PROTECTED]  2002-04-30 18:48 ---
The server resumed pausing again, I managed to get the following live trace I 
did a where a few times.. HOPE this helps!!!

gdb httpd 28168
GNU gdb 19991004
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux"...(no debugging symbols found)...

/home/cvsroot/CVSROOT/28168: No such file or directory.
Attaching to program: /usr/sbin/httpd, Pid 28168
Reading symbols from /lib/libpam.so.0...(no debugging symbols found)...done.
Reading symbols from /lib/libdl.so.2...done.
Reading symbols from /lib/libcrypt.so.1...done.
Reading symbols from /lib/libresolv.so.2...done.
Reading symbols from /lib/libm.so.6...done.
Reading symbols from /lib/libnsl.so.1...done.
Reading symbols from /lib/libdb.so.3...done.
Reading symbols from /lib/libc.so.6...done.
Reading symbols from /lib/ld-linux.so.2...done.
Reading symbols from /lib/libnss_files.so.2...done.
Reading symbols from /usr/lib/gconv/ISO8859-1.so...done.
0x401800de in __select () from /lib/libc.so.6
(gdb) where
#0  0x401800de in __select () from /lib/libc.so.6
#1  0x401c314c in ?? () from /lib/libc.so.6
#2  0x813d249 in ap_child_terminate ()
#3  0x813d903 in main ()
#4  0x400eb9cb in __libc_start_main (main=0x813d5bc , argc=1, 
argv=0xbb14, 
init=0x8062b4c <_init>, fini=0x816b96c <_fini>, rtld_fini=0x4000aea0 
<_dl_fini>, 
stack_end=0xbb0c) at ../sysdeps/generic/libc-start.c:92
(gdb) where
#0  0x401800de in __select () from /lib/libc.so.6
#1  0x401c314c in ?? () from /lib/libc.so.6
#2  0x813d249 in ap_child_terminate ()
#3  0x813d903 in main ()
#4  0x400eb9cb in __libc_start_main (main=0x813d5bc , argc=1, 
argv=0xbb14, 
init=0x8062b4c <_init>, fini=0x816b96c <_fini>, rtld_fini=0x4000aea0 
<_dl_fini>, 
stack_end=0xbb0c) at ../sysdeps/generic/libc-start.c:92
(gdb) where
#0  0x401800de in __select () from /lib/libc.so.6
#1  0x401c314c in ?? () from /lib/libc.so.6
#2  0x813d249 in ap_child_terminate ()
#3  0x813d903 in main ()
#4  0x400eb9cb in __libc_start_main (main=0x813d5bc , argc=1, 
argv=0xbb14, 
init=0x8062b4c <_init>, fini=0x816b96c <_fini>, rtld_fini=0x4000aea0 
<_dl_fini>, 
stack_end=0xbb0c) at ../sysdeps/generic/libc-start.c:92
(gdb) where
#0  0x401800de in __select () from /lib/libc.so.6
#1  0x401c314c in ?? () from /lib/libc.so.6
#2  0x813d249 in ap_child_terminate ()
#3  0x813d903 in main ()
#4  0x400eb9cb in __libc_start_main (main=0x813d5bc , argc=1, 
argv=0xbb14, 
init=0x8062b4c <_init>, fini=0x816b96c <_fini>, rtld_fini=0x4000aea0 
<_dl_fini>, 
stack_end=0xbb0c) at ../sysdeps/generic/libc-start.c:92
(gdb) where
#0  0x401800de in __select () from /lib/libc.so.6
#1  0x401c314c in ?? () from /lib/libc.so.6
#2  0x813d249 in ap_child_terminate ()
#3  0x813d903 in main ()
#4  0x400eb9cb in __libc_start_main (main=0x813d5bc , argc=1, 
argv=0xbb14, 
init=0x8062b4c <_init>, fini=0x816b96c <_fini>, rtld_fini=0x4000aea0 
<_dl_fini>, 
stack_end=0xbb0c) at ../sysdeps/generic/libc-start.c:92
(gdb) where
#0  0x401800de in __select () from /lib/libc.so.6
#1  0x401c314c in ?? () from /lib/libc.so.6
#2  0x813d249 in ap_child_terminate ()
#3  0x813d903 in main ()
#4  0x400eb9cb in __libc_start_main (main=0x813d5bc , argc=1, 
argv=0xbb14, 
init=0x8062b4c <_init>, fini=0x816b96c <_fini>, rtld_fini=0x4000aea0 
<_dl_fini>, 
stack_end=0xbb0c) at ../sysdeps/generic/libc-start.c:92
(gdb) where
#0  0x401800de in __select () from /lib/libc.so.6
#1  0x401c314c in ?? () from /lib/libc.so.6
#2  0x813d249 in ap_child_terminate ()
#3  0x813d903 in main ()
#4  0x400eb9cb in __libc_start_main (main=0x813d5bc , argc=1, 
argv=0xbb14, 
init=0x8062b4c <_init>, fini=0x816b96c <_fini>, rtld_fini=0x4000aea0 
<_dl_fini>, 
stack_end=0xbb0c) at ../sysdeps/generic/libc-start.c:92
(gdb) quit


DO NOT REPLY [Bug 8677] New: - mod_proxy ALWAYS nukes Content-Length and Transfer-Encoding if body sent

2002-04-30 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8677

mod_proxy ALWAYS nukes Content-Length and Transfer-Encoding if body sent 

   Summary: mod_proxy ALWAYS nukes Content-Length and Transfer-
Encoding if body sent
   Product: Apache httpd-2.0
   Version: 2.0.35
  Platform: All
OS/Version: All
Status: NEW
  Severity: Normal
  Priority: Other
 Component: mod_proxy
AssignedTo: bugs@httpd.apache.org
ReportedBy: [EMAIL PROTECTED]


apparently, this was done so that ap_set_keepalive will work properly:

(proxy_http.c)
/* In order for ap_set_keepalive to work properly, we can NOT
 * have any length information stored in the output headers.

apr_table_unset(r->headers_out,"Transfer-Encoding");
apr_table_unset(r->headers_out,"Content-Length");

ap_log_error(APLOG_MARK, APLOG_DEBUG|APLOG_NOERRNO, 0, r->server,
 "proxy: start body send");
 
However, this is overbroad.  If we have Connection: close, then we're not going 
to have a keepalive connection, so we don't need or want to nuke the c-l and t-
e headers.  Refering to an earlier bug declared invalid (#8673), not every 
vendor comprehends the standards, and so might very well send a set of HTTP 
headers that is inconsistent with the standard.  mod_proxy should not touch any 
headers that it does not absolutely have to.

Here's ap_set_keepalive, just so all of the appropriate code is in one place:

AP_DECLARE(int) ap_set_keepalive(request_rec *r)
{
int ka_sent = 0;
int wimpy = ap_find_token(r->pool,
  apr_table_get(r->headers_out, "Connection"),
  "close");
const char *conn = apr_table_get(r->headers_in, "Connection");
 
/* The following convoluted conditional determines whether or not
 * the current connection should remain persistent after this response
 * (a.k.a. HTTP Keep-Alive) and whether or not the output message
 * body should use the HTTP/1.1 chunked transfer-coding.  In English,
 *
 *   IF  we have not marked this connection as errored;
 *   and the response body has a defined length due to the status code
 *   being 304 or 204, the request method being HEAD, already
 *   having defined Content-Length or Transfer-Encoding: chunked, or
 *   the request version being HTTP/1.1 and thus capable of being set
 *   as chunked [we know the (r->chunked = 1) side-effect is ugly];
 *   and the server configuration enables keep-alive;
 *   and the server configuration has a reasonable inter-request timeout;
 *   and there is no maximum # requests or the max hasn't been reached;
 *   and the response status does not require a close;
 *   and the response generator has not already indicated close;
 *   and the client did not request non-persistence (Connection: close);
 *   andwe haven't been configured to ignore the buggy twit
 *   or they're a buggy twit coming through a HTTP/1.1 proxy
 *   andthe client is requesting an HTTP/1.0-style keep-alive
 *   or the client claims to be HTTP/1.1 compliant (perhaps a proxy);
 *   THEN we can be persistent, which requires more headers be output.
 *
 * Note that the condition evaluation order is extremely important.
 */
...
}
 
the code corresponding to the Content-Length condition is:
 
&& ((r->status == HTTP_NOT_MODIFIED)
|| (r->status == HTTP_NO_CONTENT)
|| r->header_only
|| apr_table_get(r->headers_out, "Content-Length")
|| ap_find_last_token(r->pool,
  apr_table_get(r->headers_out,
"Transfer-Encoding"),
  "chunked")
|| ((r->proto_num >= HTTP_VERSION(1,1))
&& (r->chunked = 1))) /* THIS CODE IS CORRECT, see above. */


DO NOT REPLY [Bug 8678] New: - apxs not layout aware

2002-04-30 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8678

apxs not layout aware

   Summary: apxs not layout aware
   Product: Apache httpd-2.0
   Version: 2.0.35
  Platform: All
OS/Version: All
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Build
AssignedTo: bugs@httpd.apache.org
ReportedBy: [EMAIL PROTECTED]


apxs is not aware of the information given in config.layout when choosing e.g.
--enable-layout=GNU.

It assumes that libtool etc. reside in ${prefix}/build while this is not 
necessary. 
This leads to other modules being unable to install (correctly).


DO NOT REPLY [Bug 8678] - apxs not layout aware

2002-04-30 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8678

apxs not layout aware

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE



--- Additional Comments From [EMAIL PROTECTED]  2002-04-30 19:28 ---
I believe that this is fixed in CVS.  But in any case, there is another bug
on the topic already.

*** This bug has been marked as a duplicate of 8453 ***


DO NOT REPLY [Bug 8453] - apxs uses wrong path-variable for build-dir

2002-04-30 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8453

apxs uses wrong path-variable for build-dir

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]



--- Additional Comments From [EMAIL PROTECTED]  2002-04-30 19:28 ---
*** Bug 8678 has been marked as a duplicate of this bug. ***


DO NOT REPLY [Bug 8677] - mod_proxy ALWAYS nukes Content-Length and Transfer-Encoding if body sent

2002-04-30 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8677

mod_proxy ALWAYS nukes Content-Length and Transfer-Encoding if body sent

[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|mod_proxy ALWAYS nukes  |mod_proxy ALWAYS nukes
   |Content-Length and Transfer-|Content-Length and Transfer-
   |Encoding if body sent   |Encoding if body sent



--- Additional Comments From [EMAIL PROTECTED]  2002-04-30 22:04 ---
I think you have a slight misunderstanding of what a Proxy server does.  It 
doesn't just simply pass all content untouched from server to client.  It
may do all sorts of other things including changing encodings.

Now, if the server is really unconditionally stripping the content length,
I agree that doesn't sound like a good idea, especially if serving to
a HTTP/1.0 client.  But I'll leave it for someone more familiar with
mod_proxy to take a detailed look at this.


DO NOT REPLY [Bug 8683] New: - Insecure file permissions - make install

2002-04-30 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8683

Insecure file permissions - make install

   Summary: Insecure file permissions - make install
   Product: Apache httpd-1.3
   Version: 1.3.24
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Build
AssignedTo: bugs@httpd.apache.org
ReportedBy: [EMAIL PROTECTED]


When you run "make install" as root and it gets to this part:

Copying tree ./htdocs/manual -> /usr/local/apache/htdocs/manual/
Copying tree ./icons/ -> /usr/local/apache/icons/

the files it copies have a user and group id of 1078 -- the id's the files in 
the tar archive had. This isn't really secure because whichever user happens to 
have an id of 1078 can write to the files.

When installed as root, I think all installed files should have a user and 
group id of 0.


DO NOT REPLY [Bug 8424] - IPV6 and IPV4 bind

2002-04-30 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8424

IPV6 and IPV4 bind





--- Additional Comments From [EMAIL PROTECTED]  2002-04-30 22:48 ---
Thanks for this info, i just want to add that Listen [0::0]:80 is also required 
for the ipv6 binding, but i am wondering why he don't automatically bind 
on both ipv4 and ipv6