You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@httpd.apache.org by ji...@apache.org on 2012/09/24 23:01:01 UTC
svn commit: r1389575 - /httpd/httpd/trunk/CHANGES
Author: jim
Date: Mon Sep 24 21:01:01 2012
New Revision: 1389575
URL: http://svn.apache.org/viewvc?rev=1389575&view=rev
Log:
mod_header changes
Modified:
httpd/httpd/trunk/CHANGES
Modified: httpd/httpd/trunk/CHANGES
URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/CHANGES?rev=1389575&r1=1389574&r2=1389575&view=diff
==============================================================================
--- httpd/httpd/trunk/CHANGES [utf-8] (original)
+++ httpd/httpd/trunk/CHANGES [utf-8] Mon Sep 24 21:01:01 2012
@@ -1,6 +1,10 @@
-*- coding: utf-8 -*-
Changes with Apache 2.5.0
+ *) mod_headers: New params: %l for load averages, %i for an
+ idle percentage rating of httpd, and %b for a busy percentage
+ rating. [Jim Jagielski]
+
*) core: New functions to obtain load parameters: ap_get_sload()
and ap_get_loadavg(). [Jim Jagielski]
Re: svn commit: r1389575 - /httpd/httpd/trunk/CHANGES
Posted by Graham Leggett <mi...@sharp.fm>.
On 26 Sep 2012, at 12:22 AM, Daniel Ruggeri <DR...@primary.net> wrote:
> On the flip side, giving this information out in http headers could be
> dangerous. Taking httpd out of the equation, this has pretty wide
> implications. Depending on how the calculations are communicated, one
> may be able to determine how effective a denial of service attack is
> based on the numbers returned by the server. If the end user has a way
> to influence the load balancer and pick the backend, they could
> systematically target each backend (with realtime feedback) and take one
> out at a time. Sure, httpd could drop this header before replying to the
> client, but I foresee a huge lack adoption because httpd isn't the only
> webserver in the world (it's just the best).
What I have been keen to do for a while is to come up with a generic way for httpd to sign a group of headers, and then pass through a header with that signature attached.
A receiving server then verifies the signature header, and if the signature is valid, the headers affected are passed, but if invalid, the headers are blacked out in some fashion (blacked out not removed because the long suffering admin wants a fighting chance at debugging where his header went, while passing through servers and/or load balancers to which he may or may not have access), or the request can be rejected outright.
I have done this very successfully with single headers, but a generic way to do it with multiple headers will be ideal. This is useful in load balancing scenarios where the outermost server reads a userid and/or extracts the DN or SAN from a client certificate, and then makes that information available to inner layers, of which there may be many. In this scenario you need a way to ensure that headers can't be injected when there any many points of entry.
If the headers are outbound, you might strip the headers at the point of exit, or encrypt them.
Regards,
Graham
--
Re: svn commit: r1389575 - /httpd/httpd/trunk/CHANGES
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Sep 25, 2012, at 6:22 PM, Daniel Ruggeri <DR...@primary.net> wrote:
>
> On the flip side, giving this information out in http headers could be
> dangerous. Taking httpd out of the equation, this has pretty wide
> implications.
This is true, and that's why I'm not suggesting that httpd,
or any backend at all, default to producing these headers.
In a "typical" reverse proxy situation, I assume that the
admin of the proxy also admins (at least to some extent) the
backends, and so he/she would only enable these headers on
backends they know are being proxied. Also, the front-end
on accepting the headers from the backend would /dev/null
them, so that this info would never "leak" to the external
world.
At least, that's the scenario I'm working towards...
Re: svn commit: r1389575 - /httpd/httpd/trunk/CHANGES
Posted by Daniel Ruggeri <DR...@primary.net>.
On 9/25/2012 6:45 AM, Jim Jagielski wrote:
> The long-term intent for the above is to support a new load
> balancer provider, which uses the response header info
> from the backend for its balancing calculations. It would
> be great if we could define some sort of "universal"
> (unofficial but commonly used) header and format so that
> httpd could balancer other backends...
>
> Thoughts? Suggestions?
This has long been a thought of mine as well. I support the idea, but
there are some landmines in that field. FWIW, in my environment one
could easily write a simple servlet filter to sit in front of J2EE
containers to provide this info. Agreed, no "standard" header exists but
I dare say that if one is chosen, it'd be great for the format to be
well communicated and shared for many backend providers.
On the flip side, giving this information out in http headers could be
dangerous. Taking httpd out of the equation, this has pretty wide
implications. Depending on how the calculations are communicated, one
may be able to determine how effective a denial of service attack is
based on the numbers returned by the server. If the end user has a way
to influence the load balancer and pick the backend, they could
systematically target each backend (with realtime feedback) and take one
out at a time. Sure, httpd could drop this header before replying to the
client, but I foresee a huge lack adoption because httpd isn't the only
webserver in the world (it's just the best).
First crack at a header proposal?
A response header named X-Load-Factor which contains an integer from 0
to a mutually agreed upon integer (0 to 100 for example). The higher the
number, the more load the server advertises it would like to handle.
Servers are given the freedom to choose how they calculate the value of
the header. An upstream loadbalancer or proxy would therefore direct
traffic to the backend that advertises the highest load factor or fall
back to a different load algorithm should two backends advertise the
same load factor. In the event all backends do not have the header, the
fallback load algorithm is used. In the event one backend does not
return the X-Load-Factor header, its practical load factor becomes 0.
--
Daniel Ruggeri
Re: svn commit: r1389575 - /httpd/httpd/trunk/CHANGES
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Sep 24, 2012, at 5:01 PM, jim@apache.org wrote:
> -*- coding: utf-8 -*-
> Changes with Apache 2.5.0
>
> + *) mod_headers: New params: %l for load averages, %i for an
> + idle percentage rating of httpd, and %b for a busy percentage
> + rating. [Jim Jagielski]
> +
The long-term intent for the above is to support a new load
balancer provider, which uses the response header info
from the backend for its balancing calculations. It would
be great if we could define some sort of "universal"
(unofficial but commonly used) header and format so that
httpd could balancer other backends...
Thoughts? Suggestions?