DO NOT REPLY [Bug 11993] - PDFs served through ProxyPass show up blank

[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=11993

PDFs served through ProxyPass show up blank





--- Additional Comments From [EMAIL PROTECTED]  2003-10-01 04:59 ---
I am seeing this bug in 2.0.47(frontend)and 1.3.27(backend) as well

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 21736] - not possible to modify response header when default_handler result a HTTP_NOT_MODIFIED

[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=21736

not possible to modify response header when default_handler result a 
HTTP_NOT_MODIFIED

[EMAIL PROTECTED] changed:

   What|Removed |Added

   Severity|Normal  |Enhancement



--- Additional Comments From [EMAIL PROTECTED]  2003-10-01 06:41 ---
Ricardo, you cannot modify the server header with mod_headers. No way. In fact,
it is not that useful as you might think. You can, however, use the ServerTokens
directive to *reduce* the amount of information that is given with the server
header. Alternatively you may hack the code, of course. You issue is a 
'wontfix'.

For the future: please open a new report for different issues and do not put
different things together. Thanks.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 8677] - mod_proxy ALWAYS nukes Content-Length

[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

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]
 Status|CLOSED  |REOPENED
 Resolution|FIXED   |



--- Additional Comments From [EMAIL PROTECTED]  2003-10-01 16:22 ---
I do still have problems with Windows Update using apache 2.0.47.

Cu

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 23548] New: - prefork model on solaris 2.6 mod_ldap leaves connections to ldap in close_wait

[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=23548

prefork model on solaris 2.6 mod_ldap leaves connections to ldap in close_wait

   Summary: prefork model on solaris 2.6 mod_ldap leaves connections
to ldap in close_wait
   Product: Apache httpd-2.0
   Version: 2.0.47
  Platform: Sun
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: mod_ldap
AssignedTo: bugs@httpd.apache.org
ReportedBy: [EMAIL PROTECTED]


We are running apache 2.0.47 in prefork model on solaris 2.6 and solaris 2.8. 
We are using the 
ldap authenticator which is still in experimental mode using the NETSCAPE C 
libraries (without 
SSL).

Authentication to ldap using .htaccess files occurs flawlessly.  Each apache 
child holds open a 
connection to ldap on port 389 for the specified length of time.  However, when 
that time expires 
or the port 389 connection is closed, the apache child does not reap the 
connection and it remains 
stuck in close_wait.

Eventually Apache reaches the file descriptor limit (set to 64) and stop 
accepting new connections.  
We don't want to raise the FD limit we would like to get to the root cause.  
Any ideas?

We do not see this on solaris 2.8!

APPENDIX (error log , truss, lsof output from parent and children).

ERROR LOG INDICATES THE SYMPTOM:

Tue Sep 30 18:40:48 2003] [error] [client 10.0.0.2] (24)Too many open files

TRUSS of parent seems normal:

15598:  poll(0xEFFFDA90, 0, 1000)   = 0
15598:  waitid(7, 0, 0xE9A0, 0107)  = 0
15598:siginfo: SIG#0
15598:  poll(0xEFFFDA90, 0, 1000)   = 0
15598:  waitid(7, 0, 0xE9A0, 0107)  = 0
15598:siginfo: SIG#0
15598:  poll(0xEFFFDA90, 0, 1000)   = 0
15598:  waitid(7, 0, 0xE9A0, 0107)  = 0
15598:siginfo: SIG#0
(SO ON AND SO FORTH)

LSOF OF A CHILD SHOWS THE STUCK CLOSE_WAITS:
COMMAND  PID USER   FD   TYPE DEVICE SIZE/OFF  NODE NAME
apache2047   5435 www9u  inet 0x90c4c9d8 0t37   TCP 
solars2.6:80->eam-
sj2.cisco.com:37648 (CLOSE_WAIT)
apache2047   5435 www   10u  inet 0x9278db100t427   TCP 
solars2.6:50616->netscape-
ldap:389 (CLOSE_WAIT)
apache2047   5435 www   11u  inet 0xad5a39580t386   TCP 
solars2.6:50627->netscape-
ldap:389 (CLOSE_WAIT)
apache2047   5435 www   12u  inet 0x83b41ec8   0t1612   TCP 
solars2.6:50630->netscape-
ldap:389 (CLOSE_WAIT)
apache2047   5435 www   13u  inet 0x7e1cf1600t744   TCP 
solars2.6:50666->netscape-
ldap:389 (CLOSE_WAIT)
apache2047   5435 www   14u  inet 0x7231f7c8   0t3507   TCP 
solars2.6:50670->netscape-
ldap:389 (CLOSE_WAIT)
apache2047   5435 www   15u  inet 0xad5a2f580t361   TCP 
solars2.6:51412->netscape-
ldap:389 (CLOSE_WAIT)
apache2047   5435 www   16u  inet 0x76985e38  0t12054   TCP 
solars2.6:35189->netscape-
ldap:389 (CLOSE_WAIT)
apache2047   5435 www   17u  inet 0x9278aa880t333   TCP 
solars2.6:37367->netscape-
ldap:389 (CLOSE_WAIT)
apache2047   5435 www   18u  inet 0x7d6771c0   0t5455   TCP 
solars2.6:40510->netscape-
ldap:389 (CLOSE_WAIT)
apache2047   5435 www   19u  inet 0x81a710f8   0t3548   TCP 
solars2.6:41520->netscape-
ldap:389 (CLOSE_WAIT)
apache2047   5435 www   20u  inet 0x7e1cfc60   0t6510   TCP 
solars2.6:41536->netscape-
ldap:389 (CLOSE_WAIT)
apache2047   5435 www   21u  inet 0x90c74a780t732   TCP 
solars2.6:43119->netscape-
ldap:389 (CLOSE_WAIT)
apache2047   5435 www   22u  inet 0x71cee450   0t6255   TCP 
solars2.6:52432->netscape-
ldap:389 (CLOSE_WAIT)
apache2047   5435 www   23u  inet 0x759de7d00t366   TCP 
solars2.6:53967->netscape-
ldap:389 (CLOSE_WAIT)
apache2047   5435 www   24u  inet 0x839526b8   0t3942   TCP 
solars2.6:56627->netscape-
ldap:389 (CLOSE_WAIT)
apache2047   5435 www   25u  inet 0x83b435d00t366   TCP 
solars2.6:57230->netscape-
ldap:389 (CLOSE_WAIT)
apache2047   5435 www   26u  inet 0x9c7aaeb80t422   TCP 
solars2.6:57249->netscape-
ldap:389 (CLOSE_WAIT)
apache2047   5435 www   27u  inet 0x72b4bd580t366   TCP 
solars2.6:57250->netscape-
ldap:389 (CLOSE_WAIT)
apache2047   5435 www   28u  inet 0x83b405480t821   TCP 
solars2.6:57267->netscape-
ldap:389 (CLOSE_WAIT)
apache2047   5435 www   29u  inet 0x9278cd900t366   TCP 
solars2.6:57348->netscape-
ldap:389 (CLOSE_WAIT)
apache2047   5435 www   30u  inet 0x83861140   0t8091   TCP 
solars2.6:57513->netscape-
ldap:389 (CLOSE_WAIT)
apache2047   5435 www   31u  inet 0x9c79aeb00t380   TCP 
solars2.6:58749->netscape-
ldap:389 (CLOSE_WAIT)
apach

DO NOT REPLY [Bug 23550] New: - mod_mem_cache replaces HTTP Status 301 with 200

[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=23550

mod_mem_cache replaces HTTP Status 301 with 200

   Summary: mod_mem_cache replaces HTTP Status 301 with 200
   Product: Apache httpd-2.0
   Version: 2.0.47
  Platform: PC
OS/Version: Linux
Status: UNCONFIRMED
  Severity: Major
  Priority: Other
 Component: mod_cache
AssignedTo: bugs@httpd.apache.org
ReportedBy: [EMAIL PROTECTED]


When apache is configured as a reverse proxy with mod_mem_cache enabled, it will
cache 301 responses from the backend. Whether this behaviour is desireable or
not, I really do not know, mod_disk_cache for example will not cache these
responses because mod_disk_cache does not cache responses without Content-Length
header set.

Now, when we hit the memory-cached object, mod_mem_cache returns the original
301 response with a replaced HTTP status of 200. This causes clients to not
follow the redirect.

I will try to illustrate this:

request:
GET /foo HTTP/1.1
Host: www.foo.tld

1st response, before caching:
HTTP/1.1 301 Moved Permanently
Location: http://www.foo.tld/foo/

subsequent response, on same request:
HTTP/1.1 200 OK
Location: http://www.foo.tld/foo/

=> Client ignores Location: header

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 23550] - mod_mem_cache replaces HTTP Status 301 with 200

[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=23550

mod_mem_cache replaces HTTP Status 301 with 200

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  everconfirmed|0   |1

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 21348] - windowsupdate-site over proxy failed

[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=21348

windowsupdate-site over proxy failed





--- Additional Comments From [EMAIL PROTECTED]  2003-10-01 16:19 ---
I have this problem too, with apache 2.0.47. Is there a offical solution 
avaiable?

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]