[Bug 60251] mod_remoteip discards additional address when mod_rewrite rule is triggered

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=60251

Jay Klehr  changed:

   What|Removed |Added

 CC||j...@diablomedia.com

-- 
You are receiving this mail because:
You are the assignee for the bug.

-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org

[Bug 58292] FallbackResource breaks chunked encoding sometimes

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=58292

Raphaël Droz  changed:

   What|Removed |Added

 CC||raphael.d...@gmail.com

--- Comment #2 from Raphaël Droz  ---
Created attachment 34371
  --> https://bz.apache.org/bugzilla/attachment.cgi?id=34371=edit
sample vhost demo'ing the "missing last chunk" behavior

Thank you for the patch!
Did you considered backporting this to 2.4.x?
It even apply cleanly for version as old as Apache 2.4.10.



For search engines friendliness:
> curl: (18) transfer closed with outstanding read data remaining
(could have saved me a couple of hours to hit this bug sooner)

I'm also attaching the configuration demonstrating the issue.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org

[Bug 60251] mod_remoteip discards additional address when mod_rewrite rule is triggered

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=60251

--- Comment #1 from Ari Pringle  ---
I enabled LogLevel rewrite:trace8 remoteip:trace8 on the system, and included
the error log output below. It seems that mod_remoteip is getting executed
again after mod_rewrite performs the INTERNAL_REDIRECT, and presumably working
on already-modified X-Forwarded-For header. Would it be feasible to detect if
such a redirect has happened and not re-process the request in that case?

This case seems similar to this patch:
https://bz.apache.org/bugzilla/show_bug.cgi?id=49839

For what it's worth, a colleague of mine noted that the code from the above
patch doesn't seem to exist in the current mod_remoteip.c source.

---

[Thu Oct 13 21:19:29.913894 2016] [remoteip:trace1] [pid 37]
mod_remoteip.c(423): [client 3.3.3.3:53539] Using 3.3.3.3 as client's IP by
proxies 100.100.100.1
[Thu Oct 13 21:19:29.914754 2016] [rewrite:trace3] [pid 37] mod_rewrite.c(477):
[client 3.3.3.3:53539] 3.3.3.3 - -
[localhost/sid#7f85f6945470][rid#7f85f68bd0a0/initial] [perdir /app/httpdocs/]
strip per-dir prefix: /app/httpdocs/invalidurl -> invalidurl
[Thu Oct 13 21:19:29.914771 2016] [rewrite:trace3] [pid 37] mod_rewrite.c(477):
[client 3.3.3.3:53539] 3.3.3.3 - -
[localhost/sid#7f85f6945470][rid#7f85f68bd0a0/initial] [perdir /app/httpdocs/]
applying pattern '^.*$' to uri 'invalidurl'
[Thu Oct 13 21:19:29.914853 2016] [rewrite:trace4] [pid 37] mod_rewrite.c(477):
[client 3.3.3.3:53539] 3.3.3.3 - -
[localhost/sid#7f85f6945470][rid#7f85f68bd0a0/initial] [perdir /app/httpdocs/]
RewriteCond: input='/app/httpdocs/invalidurl' pattern='!-s' => matched
[Thu Oct 13 21:19:29.914863 2016] [rewrite:trace2] [pid 37] mod_rewrite.c(477):
[client 3.3.3.3:53539] 3.3.3.3 - -
[localhost/sid#7f85f6945470][rid#7f85f68bd0a0/initial] [perdir /app/httpdocs/]
rewrite 'invalidurl' -> 'index.php'
[Thu Oct 13 21:19:29.914872 2016] [rewrite:trace3] [pid 37] mod_rewrite.c(477):
[client 3.3.3.3:53539] 3.3.3.3 - -
[localhost/sid#7f85f6945470][rid#7f85f68bd0a0/initial] [perdir /app/httpdocs/]
add per-dir prefix: index.php -> /app/httpdocs/index.php
[Thu Oct 13 21:19:29.914884 2016] [rewrite:trace2] [pid 37] mod_rewrite.c(477):
[client 3.3.3.3:53539] 3.3.3.3 - -
[localhost/sid#7f85f6945470][rid#7f85f68bd0a0/initial] [perdir /app/httpdocs/]
strip document_root prefix: /app/httpdocs/index.php -> /index.php
[Thu Oct 13 21:19:29.914892 2016] [rewrite:trace1] [pid 37] mod_rewrite.c(477):
[client 3.3.3.3:53539] 3.3.3.3 - -
[localhost/sid#7f85f6945470][rid#7f85f68bd0a0/initial] [perdir /app/httpdocs/]
internal redirect with /index.php [INTERNAL REDIRECT]
[Thu Oct 13 21:19:29.915247 2016] [remoteip:trace1] [pid 37]
mod_remoteip.c(423): [client 2.2.2.2:53539] Using 2.2.2.2 as client's IP by
proxies 100.100.100.2
[Thu Oct 13 21:19:29.915304 2016] [rewrite:trace3] [pid 37] mod_rewrite.c(477):
[client 2.2.2.2:53539] 2.2.2.2 - -
[localhost/sid#7f85f6945470][rid#7f85f68b9a60/initial/redir#1] [perdir
/app/httpdocs/] strip per-dir prefix: /app/httpdocs/index.php -> index.php
[Thu Oct 13 21:19:29.915358 2016] [rewrite:trace3] [pid 37] mod_rewrite.c(477):
[client 2.2.2.2:53539] 2.2.2.2 - -
[localhost/sid#7f85f6945470][rid#7f85f68b9a60/initial/redir#1] [perdir
/app/httpdocs/] applying pattern '^.*$' to uri 'index.php'
[Thu Oct 13 21:19:29.915372 2016] [rewrite:trace4] [pid 37] mod_rewrite.c(477):
[client 2.2.2.2:53539] 2.2.2.2 - -
[localhost/sid#7f85f6945470][rid#7f85f68b9a60/initial/redir#1] [perdir
/app/httpdocs/] RewriteCond: input='/app/httpdocs/index.php' pattern='!-s' =>
not-matched
[Thu Oct 13 21:19:29.915380 2016] [rewrite:trace1] [pid 37] mod_rewrite.c(477):
[client 2.2.2.2:53539] 2.2.2.2 - -
[localhost/sid#7f85f6945470][rid#7f85f68b9a60/initial/redir#1] [perdir
/app/httpdocs/] pass through /app/httpdocs/index.php

-- 
You are receiving this mail because:
You are the assignee for the bug.

-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org

[Bug 60251] New: mod_remoteip discards additional address when mod_rewrite rule is triggered

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=60251

Bug ID: 60251
   Summary: mod_remoteip discards additional address when
mod_rewrite rule is triggered
   Product: Apache httpd-2
   Version: 2.4.23
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P2
 Component: mod_remoteip
  Assignee: bugs@httpd.apache.org
  Reporter: aprin...@gmail.com

I've been testing this on a Debian Jessie build (apache 2.4.10), as well as a
Debian Stretch build (apache 2.4.23), with the same results.

In my configuration, mod_remoteip has a single internal trusted proxy, and
X-Forwarded-For is evaluated for additional IPs. Under normal circumstances, it
correctly "stops" at the first untrusted IP, which becomes REMOTE_ADDR.

However, when a mod_rewrite rule is triggered, it seems to discard that IP
address and continue moving up the X-Forwarded-For header, making the second
untrusted IP become the REMOTE_ADDR.

I'm including what I believe is the relevant configuration, but let me know if
further details are needed:

RemoteIPHeader X-Forwarded-For
RemoteIPInternalProxy ::1
DocumentRoot /app/httpdocs


Require all granted
AllowOverride None

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-s
RewriteRule ^.*$ index.php


In the following tests, I'll connecting from localhost, which is ::1 (the
defined RemoteIPInternalProxy). My index.php file is just echoing out the
relevant $_SERVER variables.

In the first case, I hit /index.php directly, which does NOT trigger a
RewriteRule. The REMOTE_ADDR becomes the right-most untrusted IP address,
3.3.3.3. This is, I believe, the correct behavior:

# curl -H "X-Forwarded-For: 1.1.1.1, 2.2.2.2, 3.3.3.3"
http://localhost/index.php
X-Forwarded-For: 1.1.1.1, 2.2.2.2
REMOTE_ADDR: 3.3.3.3

Now, if I hit an invalid URL, the RewriteRule is triggered and rewritten to
index.php. It appears that 3.3.3.3 is then discarded:

# curl -H "X-Forwarded-For: 1.1.1.1, 2.2.2.2, 3.3.3.3"
http://localhost/invalidurl
X-Forwarded-For: 1.1.1.1
REMOTE_ADDR: 2.2.2.2



To show additional behavior, here's a more complicated example that shows that
additional InternalProxies AND TrustedProxies are evaluated after the untrusted
IP is discarded:

RemoteIPHeader X-Forwarded-For
RemoteIPInternalProxy ::1
RemoteIPTrustedProxy 100.100.100.0/24
RemoteIPProxiesHeader X-Trusted-Proxies

In the first case, the trusted proxy is added to the X-Trusted-Proxies header,
and REMOTE_ADDR becomes the first untrusted IP (3.3.3.3). This is the correct
behavior:

# curl -H "X-Forwarded-For: 1.1.1.1, 2.2.2.2, 100.100.100.2, ::1, 3.3.3.3,
100.100.100.1" http://localhost/index.php
X-Forwarded-For: 1.1.1.1, 2.2.2.2, 100.100.100.2, ::1
X-Trusted-Proxies: 100.100.100.1
REMOTE_ADDR: 3.3.3.3

But again, by triggering a RewriteRule, the 3.3.3.3 address is discarded,
Internal & Trusted proxies seem to be evaluated again (X-Trusted-Proxies is now
100.100.100.2 instead of 100.100.100.1), and the REMOTE_ADDR becomes the second
untrusted IP, 2.2.2.2:

# curl -H "X-Forwarded-For: 1.1.1.1, 2.2.2.2, 100.100.100.2, ::1, 3.3.3.3,
100.100.100.1" http://localhost/invalidurl
X-Forwarded-For: 1.1.1.1
X-Trusted-Proxies: 100.100.100.2
REMOTE_ADDR: 2.2.2.2

-- 
You are receiving this mail because:
You are the assignee for the bug.

-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org

[Bug 60249] New: SetEnv, PassEnv, etc accept '=' in variable names

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=60249

Bug ID: 60249
   Summary: SetEnv, PassEnv, etc accept '=' in variable names
   Product: Apache httpd-2
   Version: 2.5-HEAD
  Hardware: PC
OS: Mac OS X 10.4
Status: NEW
  Severity: normal
  Priority: P2
 Component: mod_env
  Assignee: bugs@httpd.apache.org
  Reporter: pobo...@gmail.com

In various functions, a config such as:

SetEnv MY_ENV_VAR=blah

can be passed to mod_env, which is silently accepted as the single-argument
form of the directive.

We've had multiple incidents where I work of people providing config of this
form; generally due to copying them from shell env var statements or mistakenly
using shell-style env assignment out of habit.  Since '=' is invalid in Env var
names across platforms and in relevant RFCs, it seems like this should signal
an error (apologies if it does already, but I haven't been able to find where
it does/would) 

I've had trouble finding what proper error-handling is in Apache files, so I
don't want to suggest any particular behavior, but whatever error handling
generally is in such places should be applied in cases where this happens.

-- 
You are receiving this mail because:
You are the assignee for the bug.

-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org

[Bug 60244] mod_http2 causes serialized requests if there are parallel long running requests on the same connection

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=60244

--- Comment #5 from Reno Reckling  ---
I went for mpm_event + mod_fcgid which works nicely for php. Thank you

-- 
You are receiving this mail because:
You are the assignee for the bug.

-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org

[Bug 60244] mod_http2 causes serialized requests if there are parallel long running requests on the same connection

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=60244

Stefan Eissing  changed:

   What|Removed |Added

 Status|NEEDINFO|RESOLVED
 Resolution|--- |WORKSFORME

-- 
You are receiving this mail because:
You are the assignee for the bug.

-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org