You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@httpd.apache.org by ia...@apache.org on 2005/07/17 07:12:12 UTC
svn commit: r219372 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h
modules/proxy/mod_proxy.c modules/proxy/mod_proxy.h
Author: ianh
Date: Sat Jul 16 22:12:10 2005
New Revision: 219372
URL: http://svn.apache.org/viewcvs?rev=219372&view=rev
Log:
This patch adds a new hook (request_status) that gets ran in proxy_handler
just before the final return. This gives modules an opportunity to do
something based on the proxy status.
A couple of examples where this is useful:
-You are using a caching module and would rather return stale content rather
than an error to the client if the origin is down.
-you proxy some subrequests (using SSI - mod_include) and do not want SSI
errors when the backend is down. If you would normally return
HTTP_BAD_GATEWAY, you may have a module that serves some other content.
new hook -- so mmn bump.. i made it a major one, hope thats ok
Patch From Brian Akins <Brian.Akins turner.com>
Modified:
httpd/httpd/trunk/CHANGES
httpd/httpd/trunk/include/ap_mmn.h
httpd/httpd/trunk/modules/proxy/mod_proxy.c
httpd/httpd/trunk/modules/proxy/mod_proxy.h
Modified: httpd/httpd/trunk/CHANGES
URL: http://svn.apache.org/viewcvs/httpd/httpd/trunk/CHANGES?rev=219372&r1=219371&r2=219372&view=diff
==============================================================================
--- httpd/httpd/trunk/CHANGES (original)
+++ httpd/httpd/trunk/CHANGES Sat Jul 16 22:12:10 2005
@@ -1,5 +1,10 @@
Changes with Apache 2.1.7
[Remove entries to the current 2.0 section below, when backported]
+
+ *) new hook (request_status) that gets ran in proxy_handler just before
+ the final return. This gives modules an opportunity to do something
+ based on the proxy status. (major MMN bump)
+ [Brian Akins <bakins turner.com>, Ian Holsman]
*) SECURITY: CAN-2005-2088
proxy: Correctly handle the Transfer-Encoding and Content-Length
Modified: httpd/httpd/trunk/include/ap_mmn.h
URL: http://svn.apache.org/viewcvs/httpd/httpd/trunk/include/ap_mmn.h?rev=219372&r1=219371&r2=219372&view=diff
==============================================================================
--- httpd/httpd/trunk/include/ap_mmn.h (original)
+++ httpd/httpd/trunk/include/ap_mmn.h Sat Jul 16 22:12:10 2005
@@ -99,12 +99,13 @@
* 20050701.0 (2.1.7-dev) Bump MODULE_MAGIC_COOKIE to "AP21"!
* 20050701.1 (2.1.7-dev) trace_enable member added to core server_config
* 20050708.0 (2.1.7-dev) Bump MODULE_MAGIC_COOKIE to "AP22"!
+ * 20050717.0 (2.1.7-dev) add proxy request_status hook
*/
#define MODULE_MAGIC_COOKIE 0x41503232UL /* "AP22" */
#ifndef MODULE_MAGIC_NUMBER_MAJOR
-#define MODULE_MAGIC_NUMBER_MAJOR 20050708
+#define MODULE_MAGIC_NUMBER_MAJOR 20050717
#endif
#define MODULE_MAGIC_NUMBER_MINOR 0 /* 0...n */
Modified: httpd/httpd/trunk/modules/proxy/mod_proxy.c
URL: http://svn.apache.org/viewcvs/httpd/httpd/trunk/modules/proxy/mod_proxy.c?rev=219372&r1=219371&r2=219372&view=diff
==============================================================================
--- httpd/httpd/trunk/modules/proxy/mod_proxy.c (original)
+++ httpd/httpd/trunk/modules/proxy/mod_proxy.c Sat Jul 16 22:12:10 2005
@@ -732,9 +732,12 @@
int post_status = proxy_run_post_request(worker, balancer, r, conf);
if (post_status == DECLINED) {
post_status = OK; /* no post_request handler available */
- /* TODO: reclycle direct worker */
+ /* TODO: recycle direct worker */
}
}
+
+ proxy_run_request_status(&access_status, r);
+
return access_status;
}
@@ -1881,6 +1884,7 @@
APR_HOOK_LINK(canon_handler)
APR_HOOK_LINK(pre_request)
APR_HOOK_LINK(post_request)
+ APR_HOOK_LINK(request_status)
)
APR_IMPLEMENT_EXTERNAL_HOOK_RUN_FIRST(proxy, PROXY, int, scheme_handler,
@@ -1907,4 +1911,8 @@
balancer,r,conf),DECLINED)
APR_IMPLEMENT_OPTIONAL_HOOK_RUN_ALL(proxy, PROXY, int, fixups,
(request_rec *r), (r),
+ OK, DECLINED)
+APR_IMPLEMENT_OPTIONAL_HOOK_RUN_ALL(proxy, PROXY, int, request_status,
+ (int *status, request_rec *r),
+ (status, r),
OK, DECLINED)
Modified: httpd/httpd/trunk/modules/proxy/mod_proxy.h
URL: http://svn.apache.org/viewcvs/httpd/httpd/trunk/modules/proxy/mod_proxy.h?rev=219372&r1=219371&r2=219372&view=diff
==============================================================================
--- httpd/httpd/trunk/modules/proxy/mod_proxy.h (original)
+++ httpd/httpd/trunk/modules/proxy/mod_proxy.h Sat Jul 16 22:12:10 2005
@@ -375,6 +375,13 @@
proxy_balancer *balancer, request_rec *r,
proxy_server_conf *conf))
+/**
+ * request status hook
+ * It is called after all proxy processing has been done. This gives other
+ * modules a chance to create default content on failure, for example
+ */
+APR_DECLARE_EXTERNAL_HOOK(proxy, PROXY, int, request_status,
+ (int *status, request_rec *r))
/* proxy_util.c */
@@ -541,6 +548,14 @@
proxy_balancer *balancer,
request_rec *r,
proxy_server_conf *conf);
+
+/**
+ * Request status function
+ * @param status status of proxy request
+ * @return OK or DECLINED
+ */
+ PROXY_DECLARE(int) ap_proxy_request_status(int *status, request_rec *r);
+
/**
* Deternime backend hostname and port
* @param p memory pool used for processing
Re: svn commit: r219372 - in /httpd/httpd/trunk: CHANGES
include/ap_mmn.h modules/proxy/mod_proxy.c modules/proxy/mod_proxy.h
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 07:57 PM 7/17/2005, Ian Holsman wrote:
>ok..
>I'll go fix the structure.
>I wasn't sure what the difference was.
>>A new structure member (at the end of an httpd-allocated structure)
>>or new function are minor bumps; which this patch falls under.
>>The user updating should not need to update their module, because
>>the expectations when such modules were built have not changed.
I should have pointed out that if the sizeof() is well known,
and we know of/expect developers to allocate it for themselves,
then we would have to have a major bump; as long as httpd has
an allocator for the structure (which observes the now-current
sizeof()) then we are fine :)
This really makes me pause and consider; we really need an accessor
to define the version/length of specific apache defined structures;
low-level modules can check if they need to know they are compatible.
Good change for Apache 2.2's API?
Bill
Re: svn commit: r219372 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h
modules/proxy/mod_proxy.c modules/proxy/mod_proxy.h
Posted by Ian Holsman <li...@holsman.net>.
William A. Rowe, Jr. wrote:
> At 12:12 AM 7/17/2005, ianh@apache.org wrote:
>
>>Author: ianh
>>Date: Sat Jul 16 22:12:10 2005
>>New Revision: 219372
>>
>>URL: http://svn.apache.org/viewcvs?rev=219372&view=rev
>>Log:
>>This patch adds a new hook (request_status) that gets ran in proxy_handler
>>just before the final return. This gives modules an opportunity to do
>>something based on the proxy status.
>>[...]
>>new hook -- so mmn bump.. i made it a major one, hope thats ok
>
>
> We only bump major when we -change- an existing API or drop an
> API which is no longer supported. E.g. anyone using the old
> major might have been using something we no longer provide.
>
ok..
I'll go fix the structure.
I wasn't sure what the difference was.
> A new structure member (at the end of an httpd-allocated structure)
> or new function are minor bumps; which this patch falls under.
> The user updating should not need to update their module, because
> the expectations when such modules were built have not changed.
>
> Bill
>
>
Re: MMN, versioning, WAS: Re: svn commit: r219372 - in /httpd/httpd/trunk ...
Posted by André Malo <nd...@perlig.de>.
* Sander Striker wrote:
> Well honestly, the way the MMN is bumped has been very arbitrary.
If so, then by accident. I also have an eye on bumps.
> If we want to go by the rules that you describe, it needs to get
> documented.
/*
* MODULE_MAGIC_NUMBER_MAJOR
* Major API changes that could cause compatibility problems for older
modules
* such as structure size changes. No binary compatibility is possible
across
* a change in the major version.
*
* MODULE_MAGIC_NUMBER_MINOR
* Minor API changes that do not cause binary compatibility problems.
* Should be reset to 0 when upgrading MODULE_MAGIC_NUMBER_MAJOR.
*
* See the MODULE_MAGIC_AT_LEAST macro below for an example.
*/
Looks like it is in ap_mmn.h :-)
> One might actually wonder what the MMN is good for nowadays anyway,
> given that we have provider versioning and better defined overall
> versioning (ie. API compatibility between minor versions).
It's a compatibility promise. Or in other words the MMNs *are* the
versioning scheme for all static APIs. We should just keep it so :)
nd
--
Wer sein Wissen nicht teilen will, besitzt wahrscheinlich zu wenig davon.
-- Unbekannt
MMN, versioning, WAS: Re: svn commit: r219372 - in /httpd/httpd/trunk
...
Posted by Sander Striker <st...@apache.org>.
William A. Rowe, Jr. wrote:
> At 12:12 AM 7/17/2005, ianh@apache.org wrote:
>
>>Author: ianh
>>Date: Sat Jul 16 22:12:10 2005
>>New Revision: 219372
>>
>>URL: http://svn.apache.org/viewcvs?rev=219372&view=rev
>>Log:
>>This patch adds a new hook (request_status) that gets ran in proxy_handler
>>just before the final return. This gives modules an opportunity to do
>>something based on the proxy status.
>>[...]
>>new hook -- so mmn bump.. i made it a major one, hope thats ok
>
>
> We only bump major when we -change- an existing API or drop an
> API which is no longer supported. E.g. anyone using the old
> major might have been using something we no longer provide.
>
> A new structure member (at the end of an httpd-allocated structure)
> or new function are minor bumps; which this patch falls under.
> The user updating should not need to update their module, because
> the expectations when such modules were built have not changed.
Well honestly, the way the MMN is bumped has been very arbitrary.
If we want to go by the rules that you describe, it needs to get
documented.
One might actually wonder what the MMN is good for nowadays anyway,
given that we have provider versioning and better defined overall
versioning (ie. API compatibility between minor versions).
Sander
Re: svn commit: r219372 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h
modules/proxy/mod_proxy.c modules/proxy/mod_proxy.h
Posted by Mladen Turk <mt...@apache.org>.
Bill Stoddard wrote:
> William A. Rowe, Jr. wrote:
>>
>> A new structure member (at the end of an httpd-allocated structure)
>
> This one can be tricky to manage. Since every structure in httpd is
> accessable to modules, it is possible for a custom module to allocate
> structures and pass them back into the server. If the module allocates
> space for an old version of a structure and passes that pointer back
> into httpd, the results are, well, predictable in an unpredictable kind
> of way.
>
That's true if the module allocated struct can be used in the core
itself. I think the William is right about that, as well as you are :)
If the changed struct can be pushed back to the core and the rest of
modules, then we need a major module bump. In other case it's only the
minor, because the rest of the world will still have all the data
from the previous minor.
Regards,
Mladen.
Re: svn commit: r219372 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h
modules/proxy/mod_proxy.c modules/proxy/mod_proxy.h
Posted by Bill Stoddard <bi...@wstoddard.com>.
William A. Rowe, Jr. wrote:
> At 12:12 AM 7/17/2005, ianh@apache.org wrote:
>
>>Author: ianh
>>Date: Sat Jul 16 22:12:10 2005
>>New Revision: 219372
>>
>>URL: http://svn.apache.org/viewcvs?rev=219372&view=rev
>>Log:
>>This patch adds a new hook (request_status) that gets ran in proxy_handler
>>just before the final return. This gives modules an opportunity to do
>>something based on the proxy status.
>>[...]
>>new hook -- so mmn bump.. i made it a major one, hope thats ok
>
>
> We only bump major when we -change- an existing API or drop an
> API which is no longer supported. E.g. anyone using the old
> major might have been using something we no longer provide.
>
> A new structure member (at the end of an httpd-allocated structure)
This one can be tricky to manage. Since every structure in httpd is accessable to modules, it is possible for
a custom module to allocate structures and pass them back into the server. If the module allocates space for
an old version of a structure and passes that pointer back into httpd, the results are, well, predictable in
an unpredictable kind of way.
Bill
Re: svn commit: r219372 - in /httpd/httpd/trunk: CHANGES
include/ap_mmn.h modules/proxy/mod_proxy.c modules/proxy/mod_proxy.h
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 12:12 AM 7/17/2005, ianh@apache.org wrote:
>Author: ianh
>Date: Sat Jul 16 22:12:10 2005
>New Revision: 219372
>
>URL: http://svn.apache.org/viewcvs?rev=219372&view=rev
>Log:
>This patch adds a new hook (request_status) that gets ran in proxy_handler
>just before the final return. This gives modules an opportunity to do
>something based on the proxy status.
>[...]
>new hook -- so mmn bump.. i made it a major one, hope thats ok
We only bump major when we -change- an existing API or drop an
API which is no longer supported. E.g. anyone using the old
major might have been using something we no longer provide.
A new structure member (at the end of an httpd-allocated structure)
or new function are minor bumps; which this patch falls under.
The user updating should not need to update their module, because
the expectations when such modules were built have not changed.
Bill