DO NOT REPLY [Bug 11610] - Navigator pages truncated at 8192 bytes

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

Navigator pages truncated at 8192 bytes





--- Additional Comments From [EMAIL PROTECTED]  2002-08-10 23:01 ---
Created an attachment (id=2679)
Navigator 8192 byte truncation test cases

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

DO NOT REPLY [Bug 11610] New: - Navigator pages truncated at 8192 bytes

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

Navigator pages truncated at 8192 bytes

   Summary: Navigator pages truncated at 8192 bytes
   Product: Apache httpd-2.0
   Version: 2.0.39
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Critical
  Priority: Other
 Component: All
AssignedTo: bugs@httpd.apache.org
ReportedBy: [EMAIL PROTECTED]


In Navigator 4.75, and 4.79 HTML pages are turncated at 8192 bytes.  There are 
no messages displayed, the page just stops loading at 8192 bytes.

I have two test cases that I can forward.  One works and one doesn't work.

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

DO NOT REPLY [Bug 11608] New: - Apache fails to start. (winnt_accept: Asynchronous AcceptEx 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=11608

Apache fails to start. (winnt_accept: Asynchronous AcceptEx failed)

   Summary: Apache fails to start. (winnt_accept: Asynchronous
AcceptEx failed)
   Product: Apache httpd-2.0
   Version: 2.0.39
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Critical
  Priority: Other
 Component: Other Modules
AssignedTo: bugs@httpd.apache.org
ReportedBy: [EMAIL PROTECTED]


I have recently installed mod_jk on apache under windows 2k.  When I try to 
restart the server, it fails reporting: 
winnt_accept: Asynchronous AcceptEx failed

When i comment out the line:
Include "C:/Program Files/Apache Tomcat 4.0/conf/auto/mod_jk.conf"
it starts fine.

the following is a copy of the mod_jk.conf:

-- START mod_jk.conf --

## Auto generated on Sat Aug 10 18:01:23 ADT 2002##


  LoadModule jk_module C:/Program Files/Apache Group/Apache2/modules/mod_jk.dll




ServerName localhost

JkMount /manager ajp13
JkMount /manager/* ajp13

JkMount /examples ajp13
JkMount /examples/* ajp13

JkMount /tomcat-docs ajp13
JkMount /tomcat-docs/* ajp13

JkMount /webdav ajp13
JkMount /webdav/* ajp13

JkMount /jk ajp13
JkMount /jk/* ajp13


-- END mod_jk.conf --

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

DO NOT REPLY [Bug 11467] - Typo in htdocs/index.html.var

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

Typo in htdocs/index.html.var

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

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

DO NOT REPLY [Bug 11606] - 4 compile warnings when compiling 2.0.40 in win32 (using VC6 sp5)

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

4 compile warnings when compiling 2.0.40 in win32 (using VC6 sp5)

[EMAIL PROTECTED] changed:

   What|Removed |Added

Version|HEAD|2.0.40

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

DO NOT REPLY [Bug 11606] New: - 4 compile warnings when compiling 2.0.40 in win32 (using VC6 sp5)

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

4 compile warnings when compiling 2.0.40 in win32 (using VC6 sp5)

   Summary: 4 compile warnings when compiling 2.0.40 in win32 (using
VC6 sp5)
   Product: Apache httpd-2.0
   Version: HEAD
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: All
AssignedTo: bugs@httpd.apache.org
ReportedBy: [EMAIL PROTECTED]


Getting 4 compile warnings when compiling apache 2.0.40 win32 in win2k using 
VC6 sp5:

Below are the lines from the compilelog (I have stripped out the lines which 
isnt related to these warnings):


Build : warning : failed to (or don't know how to) build 'C:\httpd-2.0.40
\srclib\apr-util\uri\gen_uri_delims.exe'


Configuration: mod_disk_cache - Win32 Release---
-
Compiling...
mod_disk_cache.c
C:\httpd-2.0.40\modules\experimental\mod_disk_cache.c(333) : warning 
C4244: '=' : conversion from '__int64 ' to 'unsigned int ', possible loss of 
data
Linking...
   Creating library Release/mod_disk_cache.lib and object 
Release/mod_disk_cache.exp


Configuration: mod_mem_cache - Win32 Release

Compiling...
mod_mem_cache.c
C:\httpd-2.0.40\modules\experimental\mod_mem_cache.c(485) : warning 
C4244: '=' : conversion from '__int64 ' to 'unsigned int ', possible loss of 
data
C:\httpd-2.0.40\modules\experimental\mod_mem_cache.c(505) : warning 
C4244: '=' : conversion from '__int64 ' to 'unsigned int ', possible loss of 
data
C:\httpd-2.0.40\modules\experimental\mod_mem_cache.c(528) : warning 
C4244: '+=' : conversion from '__int64 ' to 'unsigned int ', possible loss of 
data
Linking...
   Creating library Release/mod_mem_cache.lib and object 
Release/mod_mem_cache.exp

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

DO NOT REPLY [Bug 10775] - SCRIPT_NAME wrong value

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

SCRIPT_NAME wrong value





--- Additional Comments From [EMAIL PROTECTED]  2002-08-10 05:20 ---
The normalized value is assigned to r->path_info
during the call to ap_directory_walk.  ap_directory_walk contains the following
comment:

/* XXX Notice that this forces path_info to be canonical.  That might
 * not be desired by all apps. ...

It would appear that any application that depends on the PATH_INFO from a uri
such as 'http://www.plover.com/cgi-bin/myprogram/http://some.other.url/' 
falls into the category of "an app that does not desire this behavior."

But there is still a bug, because ap_find_path_info assumes that the
tails of the r->path_info and r->uri will match, and they don't,
because the path_info was canonicalized in ap_directory_walk, but the
r->uri was not canonicalized.  

The ap_directory_walk comment cited above continues:

...  However, some of those same apps likely
 * have significant security holes.
 */

I believe this is referring to apps that might be invoked as
http://perl.plover.com/cgi-bin/myapp/../../../../../../../../../etc/passwd.
Canonicalizing this path may well save 'myapp' from a severe security
problem.  However, compressing repeated slashes from the path_info
does not appear to have any analogous security benefit.

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

DO NOT REPLY [Bug 10775] - SCRIPT_NAME wrong value

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

SCRIPT_NAME wrong value





--- Additional Comments From [EMAIL PROTECTED]  2002-08-10 04:34 ---
 The reference provided by John Ellson does appear to be
the same bug.

The proximate cause problem is in the function ap_find_path_info
in server/util_script.c.  It assumes that the tails
of the uri and the path_info arguments will match exactly.
But in the example case, the uri argument is '/cgi-bin/env/http://bluh'
and the path_info argument is '/http:/bluh' -- note that the other slash
before the 'bluh' is missing.  Apparently the path_info argument
(which comes directly from the request structure) has been either
garbled or inappropriately normalized.  I don't know yet where this
garbling occurs.

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

DO NOT REPLY [Bug 11601] - Failed request with 'Range' header does not return an error reply

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

Failed request with 'Range' header does not return an error reply





--- Additional Comments From [EMAIL PROTECTED]  2002-08-10 03:36 ---
Created an attachment (id=2678)
I think this might be the correct fix

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

DO NOT REPLY [Bug 11602] - REMOTE_USER variable lost in conjunction with Script directive

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

REMOTE_USER variable lost in conjunction with Script directive





--- Additional Comments From [EMAIL PROTECTED]  2002-08-10 02:39 ---
Created an attachment (id=2677)
Naive patch

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

DO NOT REPLY [Bug 11602] - REMOTE_USER variable lost in conjunction with Script directive

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

REMOTE_USER variable lost in conjunction with Script directive





--- Additional Comments From [EMAIL PROTECTED]  2002-08-10 02:37 ---
The following patch fixes this problem, but
I do not know what else it might break.

--- modules/http/http_request.c 2002/08/10 02:10:06 1.1
+++ modules/http/http_request.c 2002/08/10 02:10:38
@@ -360,6 +360,7 @@
 new->no_local_copy   = r->no_local_copy;
 new->read_length = r->read_length; /* We can only read it once */
 new->vlist_validator = r->vlist_validator;
+new->user= r->user; /* 20020809 [EMAIL PROTECTED] */
 
 new->proto_output_filters  = r->proto_output_filters;
 new->proto_input_filters   = r->proto_input_filters;

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

DO NOT REPLY [Bug 10678] - Several .htaccess files are consulted, REMOTE_USER gets dropped

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

Several .htaccess files are consulted, REMOTE_USER gets dropped





--- Additional Comments From [EMAIL PROTECTED]  2002-08-10 01:44 ---
This may be the same bug as #11602.

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

DO NOT REPLY [Bug 11602] New: - REMOTE_USER variable lost in conjunction with Script directive

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

REMOTE_USER variable lost in conjunction with Script directive

   Summary: REMOTE_USER variable lost in conjunction with Script
directive
   Product: Apache httpd-2.0
   Version: 2.0.39
  Platform: Other
OS/Version: Linux
Status: NEW
  Severity: Minor
  Priority: Other
 Component: mod_actions
AssignedTo: bugs@httpd.apache.org
ReportedBy: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]


My httpd.conf contains the following section:

   
AuthType Basic
AuthName  "Skater Support File Depository"
AuthUserFile /home/jen/passwords
 Script PUT /cgi-bin/Put

  require valid-user

   

As a belt-and-suspenders measure, the PUT method handler script
checks to make sure that the REMOTE_USER environment variable
has been populated by the server.  This is to protect 
against the possibility of misconfiguration; if someone managed
somehow to invoke the PUT handler script without having authenticated
themselves, the script would abort.  This worked with Apache 
1.3.12, 1.3.19, and 1.3.22.

However, beginning with at least Apache 2.0.36, the REMOTE_USER
variable is not set when the handler script is invoked, regardless
of whether the request included valid credentials.  The AuthUserFile
is correctly checked, and the script is only run when the credentials are valid,
but the script itself cannot determine the identity of 
the remote user.  The problem persists in 2.0.39.  

To test this, I first instrumented the script so that it would dump
out its environment to the file /tmp/Put.err.  I then used a Perl utility
to send a PUT request to the server:

PUT -C mjd:badpassword  http://www.plover.com/skatersupport/TESTFILE < /dev/null

The Put.err file did not appear, and PUT reported that the server's response
was a 401 Authorization Required.  Then I tried sending the same request
with the correct password:

PUT -C mjd:goodpassword  http://www.plover.com/skatersupport/TESTFILE <
/dev/null

Again, PUT reported a 401 error, but this time the 401 was artificially
generated by the PUT handler script.  The Put.err file did appear, and
contained a listing of the environment:


CONTENT_LENGTH: 0
CONTENT_TYPE: text/plain
DOCUMENT_ROOT: /usr/local/apache/htdocs
...
REMOTE_PORT: 4106
REQUEST_METHOD: PUT
...
SERVER_PROTOCOL: HTTP/1.1
SERVER_SIGNATURE: Apache/2.0.39 Server at www.plover.com Port
80

SERVER_SOFTWARE: Apache/2.0.39 (Unix)

As you can see, the REMOTE_USER variable is missing.  The Put.err file ended
with 

REMOTE_USER missing; generating authorization failure response.

indicating that the 401 response was from the handler script and not
from the httpd.

This may be the same bug as #10678.

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

DO NOT REPLY [Bug 11601] - Failed request with 'Range' header does not return an error reply

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

Failed request with 'Range' header does not return an error reply





--- Additional Comments From [EMAIL PROTECTED]  2002-08-10 01:21 ---
The "HTTP/1.0" in my report is a typo.
It was actually "HTTP/1.1".  
Sorry for any confusion this causes.

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

DO NOT REPLY [Bug 11601] New: - Failed request with 'Range' header does not return an error reply

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

Failed request with 'Range' header does not return an error reply

   Summary: Failed request with 'Range' header does not return an
error reply
   Product: Apache httpd-2.0
   Version: 2.0.39
  Platform: Other
   URL: http://perl.plover.com/nosuchfileasthis
OS/Version: Linux
Status: NEW
  Severity: Major
  Priority: Other
 Component: Core
AssignedTo: bugs@httpd.apache.org
ReportedBy: [EMAIL PROTECTED]


If I send a request for a nonexistent file as follows:

GET /nosuchfileasthis HTTP/1.0
Range: bytes=122-240
Host: perl.plover.com

I should get a 404 "File not found" response.  Instead, however, I get the
following erroneous response:

HTTP/1.1 206 Partial Content
Date: Sat, 10 Aug 2002 01:13:53 GMT
Server: Apache/2.0.39 (Unix)
Content-Range: bytes 122-240/288
Content-Length: 119
Content-Type: text/html; charset=iso-8859-1

h1>
The requested URL /nosuchfileasthis was not found on this server.

Apache/2.0.39 Server at pe

RFC2616 says that the 206 response is to be used only when the server has
fulfilled the partial GET request.  As you can see, the behavior here is 
bizarre 
in any case; we seem to have been given bytes 122-240 of the
internally-generated error document.

The error appears in 2.0.36 also.

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