Re: basic example shared memory code
When i delete exit(1), nothing has changed but when i commented out all the mutexes it works, counter is working well. That's great. :) that means shared memory is working well. in terms of mutexes i need to create mutex in post config in handler 1. lock mutex 2. process global variable 3. unlcok mutex If i'm right what is the problem with that code, do you have any ideas or advices about these segmentation faults. Oğuzhan TOPGÜL On Wed, Nov 23, 2011 at 12:39 AM, Sorin Manolache sor...@gmail.com wrote: On Tue, Nov 22, 2011 at 21:25, Oğuzhan TOPGÜL oguzhantop...@gmail.com wrote: hey guys, i'm in terrible with these shared memory. I tried to write a basic module by looking at the examples that basic module just holds a counter and prints it to the client. when i compile the code attached, i got no error messages. But in apache error.log file i got lots of [notice] child pid 32653 exit signal Segmentation fault (11) and my module does not working. if you have time to look at my code and send me your advices i'll be appreciated. Because i'm getting crazy about these shared memory concepts. I just want to define a global variable and process it in each request from different sources. Regards, Oğuzhan TOPGÜL First remove the exit(1) from child_init. Otherwise apache does not succeed in creating any children. If this does not solve your problem, comment all lines dealing with the mutex and retry. I'm not saying that you don't need mutexes but commenting them out would at least restrict the area where the segfaults happen. S On Tue, Nov 22, 2011 at 9:14 PM, Oğuzhan TOPGÜL oguzhantop...@gmail.com wrote: Thank you guys so much. What i want to do with shared memory is to hold the requester IPs and a counter that holds how many times an IP made request. I'm planning to hold them in a binary tree. I thought holding these IPs and counters in a file is slower than holding them in a shared memory because of the file I/O loss. And using binary tree as a data structure is going to make my search process faster and easier. Do you have any suggestions about shared memory-file usage or data structure usage. Regards Oğuzhan TOPGÜL On Tue, Nov 22, 2011 at 5:15 PM, Nick Kew n...@apache.org wrote: On Tue, 22 Nov 2011 09:41:02 -0500 Pranesh Vadhirajan vadhira...@teralogics.com wrote: Nick, can you suggest some of these higher-level abstractions, please? I have been trying to make a module of mine work with a POSIX shared memory implementation, but I'm going nowhere with that. Are you referring to the apache shared memory implementation (apr_shm_...) or something else? Either way, if you could suggest what I should look into, it would be greatly appreciated. apr_shm is the old way of doing it. Today I'd recommend looking at mod_slotmem, and the socache modules. I used the latter for mod_authn_socache, which is a simple example. -- Nick Kew
Re: 2.4.0….
On 22 Nov 2011, at 22:35, Graham Leggett wrote: On 22 Nov 2011, at 11:45 PM, Nick Kew wrote: Huh? Surely tcp details belong to the connection, and are accessible from the request_rec as r-conn-remote_ip ? They do until a load balancer comes along and sits in the way, obscuring the remote IP address. Suddenly the IP address is different on every request, even though the connection between httpd and the load balancer is constant and lasts a long time using keepalives. Wherein lies the problem. How confusing is it to have r-remote_ip and r-conn-remote_ip *and for them to be different*? These need distinct names to distinguish them! e.g. r-client_ip vs r-conn-remote_ip - obviously keep the latter! -- Nick Kew
Re: 2.4.0….
On 23 Nov 2011, at 10:02 AM, Nick Kew wrote: Wherein lies the problem. How confusing is it to have r-remote_ip and r-conn-remote_ip *and for them to be different*? These need distinct names to distinguish them! e.g. r-client_ip vs r-conn-remote_ip - obviously keep the latter! We already have remote_ip exploded as remote_addr, and then we take remote_ip and put it into REMOTE_ADDR, adding yet another name to all of that will just add more confusion :( Regards, Graham --
Re: svn commit: r1070179 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/mod_cache.xml modules/cache/cache_storage.c modules/cache/cache_storage.h modules/cache/mod_cache.c modules/cache/mod_cache.h
On 22 Nov 2011, at 11:58 PM, Stefan Fritsch wrote: From the thread, it is not clear to me that there was consensous on how to fix it. Therefore I would vote for reverting r1070179 from 2.4, fixing it in trunk, and then backporting the whole thing to 2.4 again (maybe after 2.4.0). In order to make invalidation possible, we would need to add an invalidate() function to the mod_cache provider, and keep AP_CACHE_INVALIDATE inside ap_cache_status_e. Invalidation involves marking the entry as invalidated and to be freshened on next hit, as opposed to deleted. What I could do is back out the change, and make just the above API changes, allowing us to backport this to v2.4 when we are ready. This releases v2.4 to get on with it, and keeps the option open for us to fix this properly at a future date in the v2.4 cycle when we're ready. Thoughts? Regards, Graham --
Re: Do we want to remove/deprecate mod_request?
On 22 Nov 2011, at 11:21 PM, Stefan Fritsch wrote: from a cursory glance at mod_request and apreq, it seems that mod_request offers a subset of the functionality of apreq. Graham, is that correct? If we aim for inclusion of apreq some time in 2.4.x, it may be a good idea to not add another API for the same thing. Maybe we could document that mod_request is already deprecated? Removing it now would be a shame because mod_auth_form depends on it. I think the addition of apreq is a lot more work than people realise. There is a lot of duplicated code across the server, and I think a target for v2.6 should be to consolidate and remove the duplicated code, and depend on apreq properly. This will take a while to do, and will probably involve changes to the apreq API along the way. Warning users that mod_request will be consolidated with apreq in future is a good idea. Regards, Graham --
Re: Do we want to remove/deprecate mod_request?
- Original Message - On 22 Nov 2011, at 11:21 PM, Stefan Fritsch wrote: from a cursory glance at mod_request and apreq, it seems that mod_request offers a subset of the functionality of apreq. Graham, is that correct? If we aim for inclusion of apreq some time in 2.4.x, it may be a good idea to not add another API for the same thing. Maybe we could document that mod_request is already deprecated? Removing it now would be a shame because mod_auth_form depends on it. I think the addition of apreq is a lot more work than people realise. There is a lot of duplicated code across the server, and I think a target for v2.6 should be to consolidate and remove the duplicated code, and depend on apreq properly. This will take a while to do, and will probably involve changes to the apreq API along the way. Warning users that mod_request will be consolidated with apreq in future is a good idea. +1 Regards, Graham -- i -- Igor Galić Tel: +43 (0) 664 886 22 883 Mail: i.ga...@brainsware.org URL: http://brainsware.org/ GPG: 6880 4155 74BD FD7C B515 2EA5 4B1D 9E08 A097 C9AE
Re: Effective IP address / real IP address
On 22 Nov 2011, at 11:47 PM, Stefan Fritsch wrote: I am not sure that we need that. When is it necessary versus the information in the Host header? But if others think that it would be a good idea, I am OK with it, too. Looking at c-local_addr, it seems to be tied in with some other fields in conn_rec, which will need more time to do properly, let's not delay this thing any further. For v2.4 purposes, I think I am done. I'll backport the remote_ip changes, which will resolve the mod_remoteip issue. Regards, Graham --
Re: svn commit: r1205274 - /httpd/httpd/trunk/modules/mappers/mod_negotiation.c
[snip]
mod_negotiation: don't return non-AP_FILTER_ERROR filter return
values
[snip]
+rv = ap_pass_brigade(r-output_filters, bb);
+if (rv != APR_SUCCESS) {
+if (rv != AP_FILTER_ERROR) {
+ap_log_rerror(APLOG_MARK, APLOG_DEBUG, rv, r,
+ ap_pass_brigade returned %d, rv);
+return HTTP_INTERNAL_SERVER_ERROR;
+}
+return AP_FILTER_ERROR;
+}
+return OK;
It looks like exactly this kind of code would or should be used
all over the place -- maybe we should put that in a function/macro?
[snip]
--
Igor Galić
Tel: +43 (0) 664 886 22 883
Mail: i.ga...@brainsware.org
URL: http://brainsware.org/
GPG: 6880 4155 74BD FD7C B515 2EA5 4B1D 9E08 A097 C9AE
Re: 2.4.0….
+1 for: Having the real client ip stored in r-* Some thought on name... I like r-client_ip but hold no strong opinions ;) On Nov 23, 2011, at 6:02 AM, Graham Leggett wrote: On 23 Nov 2011, at 10:02 AM, Nick Kew wrote: Wherein lies the problem. How confusing is it to have r-remote_ip and r-conn-remote_ip *and for them to be different*? These need distinct names to distinguish them! e.g. r-client_ip vs r-conn-remote_ip - obviously keep the latter! We already have remote_ip exploded as remote_addr, and then we take remote_ip and put it into REMOTE_ADDR, adding yet another name to all of that will just add more confusion :( Regards, Graham --
Re: 2.4.0….
On Nov 22, 2011, at 4:17 PM, Stefan Fritsch wrote: - add r-remote_ip See discussion... - change the prototype of the error_log hook +1
Re: Test failures and libwww-perl 6.0.3
On Wed, Nov 23, 2011 at 08:37:31AM +0100, Kaspar Brand wrote: There are two approaches to fix 1): a) turn off verify_hostname where needed (t/ssl/pr12355.t and t/ssl/pr43738.t are doing this right now) or b) specify the CA cert (generated in t/conf/ca/...) to make verification work/succeed. (b) sounds better; I presume it doesn't break with older versions of LWP? Regards, Joe
Re: Do we want to remove/deprecate mod_request?
-1 for deprecation... mod_request's API is, imo, a bit easier to stomach than apreq's On Nov 22, 2011, at 4:21 PM, Stefan Fritsch wrote: Hi, from a cursory glance at mod_request and apreq, it seems that mod_request offers a subset of the functionality of apreq. Graham, is that correct? If we aim for inclusion of apreq some time in 2.4.x, it may be a good idea to not add another API for the same thing. Maybe we could document that mod_request is already deprecated? Removing it now would be a shame because mod_auth_form depends on it. Cheers, Stefan
Re: svn commit: r1205274 - /httpd/httpd/trunk/modules/mappers/mod_negotiation.c
On Nov 23, 2011, at 7:07 AM, Igor Galić wrote:
[snip]
mod_negotiation: don't return non-AP_FILTER_ERROR filter return
values
[snip]
+rv = ap_pass_brigade(r-output_filters, bb);
+if (rv != APR_SUCCESS) {
+if (rv != AP_FILTER_ERROR) {
+ap_log_rerror(APLOG_MARK, APLOG_DEBUG, rv, r,
+ ap_pass_brigade returned %d, rv);
+return HTTP_INTERNAL_SERVER_ERROR;
+}
+return AP_FILTER_ERROR;
+}
+return OK;
It looks like exactly this kind of code would or should be used
all over the place -- maybe we should put that in a function/macro?
ap_pass_brigade_errchk(r, bb)
and the above could compress to
return ap_pass_brigade_errchk(r, bb);
+1
Unless someone beats me to it, will add to trunk and backport
to 2.4...
[RFC] further proxy/rewrite URL validation security issue (CVE-2011-4317)
Prutha Parikh from Qualys reported a variant on the CVE-2011-3368 attack
against certain mod_proxy/mod_rewrite configurations. A new CVE name,
CVE-2011-4317, has been assigned to this variant.
The configurations in question are the same as affected by -3368, e.g.:
RewriteRule ^(.*) http://www.example.com$1 [P]
and the equivalent ProxyPassMatch. Request examples are:
GET @localhost::8880 HTTP/1.0\r\n\r\n
GET qualys:@qqq.qq.qualys.com HTTP/1.0\r\n\r\n
These unfortunately do not get trapped in the request parsing trap added
in r1179239, so result in an input to rewrite rule processing which does
not match the URL-path grammar (i.e. does not start with /).
We could try improve that fix, but I think it would be simpler to change
the translate_name hooks in mod_proxy and mod_rewrite to enforce the
requirement in the right place. Other translate_name hooks do this
already.
I propose the patch below. Any comments?
Index: modules/proxy/mod_proxy.c
===
--- modules/proxy/mod_proxy.c (revision 1179633)
+++ modules/proxy/mod_proxy.c (working copy)
@@ -566,6 +566,13 @@
return OK;
}
+/* Check that the URI is valid. */
+if (!r-uri || r-uri[0] != '/') {
+ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r,
+ Invalid URI in request %s, r-the_request);
+return HTTP_BAD_REQUEST;
+}
+
/* XXX: since r-uri has been manipulated already we're not really
* compliant with RFC1945 at this point. But this probably isn't
* an issue because this is a hybrid proxy/origin server.
Index: modules/mappers/mod_rewrite.c
===
--- modules/mappers/mod_rewrite.c (revision 1179633)
+++ modules/mappers/mod_rewrite.c (working copy)
@@ -4266,6 +4266,13 @@
return DECLINED;
}
+/* Check that the URI is valid. */
+if (!r-uri || r-uri[0] != '/') {
+ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r,
+ Invalid URI in request %s, r-the_request);
+return HTTP_BAD_REQUEST;
+}
+
/*
* add the SCRIPT_URL variable to the env. this is a bit complicated
* due to the fact that apache uses subrequests and internal redirects
Re: mod_xml2enc comments
On Sun, Nov 13, 2011 at 03:42:07AM +, Nick Kew wrote: Feel free to fix issues you find. That's the advantage of having it under change control @apache.org. I don't have time/inclination, thanks. If nobody has any interest in maintaining this code, why has it been added to the tree? The ASF is not a dumping ground for dead code. Regards, Joe
Re: svn commit: r1205274 - /httpd/httpd/trunk/modules/mappers/mod_negotiation.c
On Wed, Nov 23, 2011 at 9:15 AM, Jim Jagielski j...@apache.org wrote:
On Nov 23, 2011, at 7:07 AM, Igor Galić wrote:
[snip]
mod_negotiation: don't return non-AP_FILTER_ERROR filter return
values
[snip]
+ rv = ap_pass_brigade(r-output_filters, bb);
+ if (rv != APR_SUCCESS) {
+ if (rv != AP_FILTER_ERROR) {
+ ap_log_rerror(APLOG_MARK, APLOG_DEBUG, rv, r,
+ ap_pass_brigade returned %d, rv);
+ return HTTP_INTERNAL_SERVER_ERROR;
+ }
+ return AP_FILTER_ERROR;
+ }
+ return OK;
It looks like exactly this kind of code would or should be used
all over the place -- maybe we should put that in a function/macro?
ap_pass_brigade_errchk(r, bb)
and the above could compress to
return ap_pass_brigade_errchk(r, bb);
+1
Unless someone beats me to it, will add to trunk and backport
to 2.4...
maybe additionally a char* for the caller to add a msg -- it was
useful in this case to find out what the handler was.
Re: svn commit: r1205274 - /httpd/httpd/trunk/modules/mappers/mod_negotiation.c
Add in r1205419 and used in r1205423
On Nov 23, 2011, at 9:29 AM, Eric Covener wrote:
On Wed, Nov 23, 2011 at 9:15 AM, Jim Jagielski j...@apache.org wrote:
On Nov 23, 2011, at 7:07 AM, Igor Galić wrote:
[snip]
mod_negotiation: don't return non-AP_FILTER_ERROR filter return
values
[snip]
+rv = ap_pass_brigade(r-output_filters, bb);
+if (rv != APR_SUCCESS) {
+if (rv != AP_FILTER_ERROR) {
+ap_log_rerror(APLOG_MARK, APLOG_DEBUG, rv, r,
+ ap_pass_brigade returned %d, rv);
+return HTTP_INTERNAL_SERVER_ERROR;
+}
+return AP_FILTER_ERROR;
+}
+return OK;
It looks like exactly this kind of code would or should be used
all over the place -- maybe we should put that in a function/macro?
ap_pass_brigade_errchk(r, bb)
and the above could compress to
return ap_pass_brigade_errchk(r, bb);
+1
Unless someone beats me to it, will add to trunk and backport
to 2.4...
maybe additionally a char* for the caller to add a msg -- it was
useful in this case to find out what the handler was.
Re: mod_xml2enc comments
On Wed, 23 Nov 2011 14:26:00 + Joe Orton jor...@redhat.com wrote: On Sun, Nov 13, 2011 at 03:42:07AM +, Nick Kew wrote: Feel free to fix issues you find. That's the advantage of having it under change control @apache.org. I don't have time/inclination, thanks. If nobody has any interest in maintaining this code, why has it been added to the tree? The ASF is not a dumping ground for dead code. Regards, Joe Discussed last month in http://marc.info/?t=13182843771 -- Nick Kew
RE: [RFC] further proxy/rewrite URL validation security issue (CVE-2011-4317)
-Original Message- From: Joe Orton [mailto:jor...@redhat.com] Sent: Mittwoch, 23. November 2011 15:23 To: dev@httpd.apache.org Subject: [RFC] further proxy/rewrite URL validation security issue (CVE-2011-4317) Prutha Parikh from Qualys reported a variant on the CVE-2011-3368 attack against certain mod_proxy/mod_rewrite configurations. A new CVE name, CVE-2011-4317, has been assigned to this variant. The configurations in question are the same as affected by -3368, e.g.: RewriteRule ^(.*) http://www.example.com$1 [P] and the equivalent ProxyPassMatch. Request examples are: GET @localhost::8880 HTTP/1.0\r\n\r\n GET qualys:@qqq.qq.qualys.com HTTP/1.0\r\n\r\n These unfortunately do not get trapped in the request parsing trap added in r1179239, so result in an input to rewrite rule processing which does not match the URL-path grammar (i.e. does not start with /). We could try improve that fix, but I think it would be simpler to change the translate_name hooks in mod_proxy and mod_rewrite to enforce the requirement in the right place. Other translate_name hooks do this already. I propose the patch below. Any comments? +1. Go ahead with the patch. One comment though: Shouldn't we check r-unparsed_uri as well (at least in the proxy case, as it may be used by ap_proxy_trans_match instead of r-uri)? Regards Rüdiger
Re: mod_xml2enc comments
On Wed, Nov 23, 2011 at 03:38:19PM +, Nick Kew wrote: On Wed, 23 Nov 2011 14:26:00 + Joe Orton jor...@redhat.com wrote: On Sun, Nov 13, 2011 at 03:42:07AM +, Nick Kew wrote: Feel free to fix issues you find. That's the advantage of having it under change control @apache.org. I don't have time/inclination, thanks. If nobody has any interest in maintaining this code, why has it been added to the tree? The ASF is not a dumping ground for dead code. Regards, Joe Discussed last month in http://marc.info/?t=13182843771 The DIY, sucker response to code review implies there is not in fact any interest in doing collabarative development for this code at the ASF. So, again, why do we have it in the tree? Regards, Joe
Re: 2.4.0….
There is one other mod_proxy API that I'm muddling through, and that's related to how we add balancers to a particular vhost (not hard, pretty much done) but, more importantly, how we dynamically add full vhost-like reverse proxies (extending what mod_proxy_express does)... For example, right now, the proxypass'es are all associated with a particular server. So conceptionally: Virtualhost www.foo.com ProxyPass /img balancer://foo/ ... /Virtualhost Virtualhost www.bar.com ProxyPass /img balancer://bar/ ... /Virtualhost What I'm looking at is something that allows the top-level server (or the catch-all vhost) to provide something like Virtualhost www.bar.com ProxyPass /img balancer://bar/ ProxyPass http://www.example.com/ balancer://example/ ... /Virtualhost So a req for http://www.bar.com/img/apache.gif - balancer://bar/apache.gif and a req to the *same* vhost, but for http://www.example.com/img/apache.gif goes to balancer://example/img/apache.gif Lots of ways to do that, and am looking at a non-evasive way right now, but I may require some tweaking of the proxy structs...
Re: mod_xml2enc comments
On Wed, 23 Nov 2011 16:21:44 + Joe Orton jor...@redhat.com wrote: On Wed, Nov 23, 2011 at 03:38:19PM +, Nick Kew wrote: On Wed, 23 Nov 2011 14:26:00 + Joe Orton jor...@redhat.com wrote: On Sun, Nov 13, 2011 at 03:42:07AM +, Nick Kew wrote: Feel free to fix issues you find. That's the advantage of having it under change control @apache.org. I don't have time/inclination, thanks. If nobody has any interest in maintaining this code, why has it been added to the tree? The ASF is not a dumping ground for dead code. Regards, Joe Discussed last month in http://marc.info/?t=13182843771 The DIY, sucker The what ASF. So, again, why do we have it in the tree? Because when I suggested it in the thread referenced, there was a consensus in favour. Or do you want to deny mod_proxy_html to anyone whose pages use charsets other than ASCII or UTF-8? -- Nick Kew
client_ip vs remote_ip
On 11/23/2011 2:02 AM, Nick Kew wrote: On 22 Nov 2011, at 22:35, Graham Leggett wrote: On 22 Nov 2011, at 11:45 PM, Nick Kew wrote: Huh? Surely tcp details belong to the connection, and are accessible from the request_rec as r-conn-remote_ip ? They do until a load balancer comes along and sits in the way, obscuring the remote IP address. Suddenly the IP address is different on every request, even though the connection between httpd and the load balancer is constant and lasts a long time using keepalives. Wherein lies the problem. How confusing is it to have r-remote_ip and r-conn-remote_ip *and for them to be different*? These need distinct names to distinguish them! e.g. r-client_ip vs r-conn-remote_ip - obviously keep the latter! +1 to this rename, it's much more sensible than effective, phys, et al, but reverse them. client_ip / client_addr is the immediate client of httpd, which may be a load balancer or transparent proxy or normal proxy if mod_remoteip has been introduced. remote_ip / remote_addr is the recognized _authenticated_ address. This has the additional advantage of *breaking* existing c-remote_ip references and forcing the module author to choose which they mean for their purposes (most would refer to the authenticated address). Bill
Re: client_ip vs remote_ip
On Wed, 23 Nov 2011 11:56:25 -0600 William A. Rowe Jr. wr...@rowe-clan.net wrote: +1 to this rename, it's much more sensible than effective, phys, et al, but reverse them. client_ip / client_addr is the immediate client of httpd, which may be a load balancer or transparent proxy or normal proxy if mod_remoteip has been introduced. Not really. The HTTP client is the end-of-line. The intermediary is an HTTP proxy, not a client. remote_ip / remote_addr is the recognized _authenticated_ address. Indeed, that's terminology that goes right back to apache prehistory. This has the additional advantage of *breaking* existing c-remote_ip references and forcing the module author to choose which they mean for their purposes (most would refer to the authenticated address). An interesting take on it! But use of remote_ip and remote_addr goes further than that. Changing their semantics in CGI (and its imitators from PHP to mod_rewrite) would *silently* break apps, so a firm -1 to that. And divorcing conn-remote_ip from the CGI/etc gets fearsomely confusing! -- Nick Kew
Re: client_ip vs remote_ip
On 23 Nov 2011, at 8:22 PM, Nick Kew wrote: This has the additional advantage of *breaking* existing c-remote_ip references and forcing the module author to choose which they mean for their purposes (most would refer to the authenticated address). This makes more sense to me, +1. An interesting take on it! But use of remote_ip and remote_addr goes further than that. Changing their semantics in CGI (and its imitators from PHP to mod_rewrite) would *silently* break apps, so a firm -1 to that. And divorcing conn-remote_ip from the CGI/etc gets fearsomely confusing! There is no option to silently break any app, the only way to get this functionality is for the administrator to actively enable a module like mod_remoteip (or similar module depending on your needs). In the word of load balancers, this behaviour is already well understood and supported. Regards, Graham --
Re: client_ip vs remote_ip
On Wednesday 23 November 2011, Graham Leggett wrote: On 23 Nov 2011, at 8:22 PM, Nick Kew wrote: This has the additional advantage of *breaking* existing c-remote_ip references and forcing the module author to choose which they mean for their purposes (most would refer to the authenticated address). This makes more sense to me, +1. Yes, +1 An interesting take on it! But use of remote_ip and remote_addr goes further than that. Changing their semantics in CGI (and its imitators from PHP to mod_rewrite) would *silently* break apps, so a firm -1 to that. And divorcing conn-remote_ip from the CGI/etc gets fearsomely confusing! There is no option to silently break any app, the only way to get this functionality is for the administrator to actively enable a module like mod_remoteip (or similar module depending on your needs). In the word of load balancers, this behaviour is already well understood and supported. Agreed.
Re: client_ip vs remote_ip
On Wed, 23 Nov 2011 20:29:40 +0200 Graham Leggett minf...@sharp.fm wrote: On 23 Nov 2011, at 8:22 PM, Nick Kew wrote: This has the additional advantage of *breaking* existing c-remote_ip references and forcing the module author to choose which they mean for their purposes (most would refer to the authenticated address). This makes more sense to me, +1. An interesting take on it! But use of remote_ip and remote_addr goes further than that. Changing their semantics in CGI (and its imitators from PHP to mod_rewrite) would *silently* break apps, so a firm -1 to that. And divorcing conn-remote_ip from the CGI/etc gets fearsomely confusing! There is no option to silently break any app, the only way to get this functionality is for the administrator to actively enable a module like mod_remoteip (or similar module depending on your needs). In the word of load balancers, this behaviour is already well understood and supported. Um, are you responding to an altogether different point to the one I was making? 1. wrowe was suggesting changing the semantics of remote_ip in core. 2. but REMOTE_ADDR and REMOTE_IP are widely-used in CGI, and everything else that uses CGI variables. 3. so wrowe's suggestion implies we EITHER divorce remote_ip from REMOTE_IP (confusing!) OR change the semantics of REMOTE_IP and potentially break thousands of CGI/etc apps. -- Nick Kew
Re: client_ip vs remote_ip
On 11/23/2011 12:22 PM, Nick Kew wrote: On Wed, 23 Nov 2011 11:56:25 -0600 William A. Rowe Jr.wr...@rowe-clan.net wrote: +1 to this rename, it's much more sensible than effective, phys, et al, but reverse them. client_ip / client_addr is the immediate client of httpd, which may be a load balancer or transparent proxy or normal proxy if mod_remoteip has been introduced. Not really. The HTTP client is the end-of-line. The intermediary is an HTTP proxy, not a client. Sorry. I mixed up 'client' with 'user agent' which are not exactly interchangeable. A better word here? remote_ip / remote_addr is the recognized _authenticated_ address. Indeed, that's terminology that goes right back to apache prehistory. It is the intent of all users to leverage the end user's IP for authn. That should be reflected in CGI etc below... This has the additional advantage of *breaking* existing c-remote_ip references and forcing the module author to choose which they mean for their purposes (most would refer to the authenticated address). An interesting take on it! But use of remote_ip and remote_addr goes further than that. Changing their semantics in CGI (and its imitators from PHP to mod_rewrite) would *silently* break apps, so a firm -1 to that. And divorcing conn-remote_ip from the CGI/etc gets fearsomely confusing! Ok... look, mod_remoteip does this today. Various x-remote-ip header hacks do the same thing for load balancers. What would break? The CGI values absolutely should be the end point (client's) address. Graham asks us to restore the immediate-next agent's IP address, to what ends I'm still not clear but apparently mainly for logging and diagnostics (which was already supported by mod_remoteip for all intermediary IPs). What he wants to do with the remaining remote intermediaries is not apparent. But his point is correct that it is challenging to track this in the conn rec given our request lifetime scope, and the fact that the successive clients on a single pipeline can and will change in many proxy/balancer scenarios. I completely agree remote_ip/addr is better tracked at req rec. We would just need a variable name in the conn rec for the persistant (default) ip address of the physical connection. And it seemed that you like the breakage to steer developers at the variable really of interest to them. client_ip wasn't it ;(
Re: svn commit: r1205423 - in /httpd/httpd/trunk/modules: cache/mod_cache.c mappers/mod_negotiation.c
On Wed, 23 Nov 2011, j...@apache.org wrote:
Author: jim
Date: Wed Nov 23 15:01:42 2011
New Revision: 1205423
URL: http://svn.apache.org/viewvc?rev=1205423view=rev
Log:
Use ap_pass_brigade_fchk()
Modified:
httpd/httpd/trunk/modules/cache/mod_cache.c
httpd/httpd/trunk/modules/mappers/mod_negotiation.c
Modified: httpd/httpd/trunk/modules/cache/mod_cache.c
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/cache/mod_cache.c?rev=1205423r1=1205422r2=1205423view=diff
==
--- httpd/httpd/trunk/modules/cache/mod_cache.c (original)
+++ httpd/httpd/trunk/modules/cache/mod_cache.c Wed Nov 23 15:01:42 2011
@@ -292,19 +292,11 @@ static int cache_quick_handler(request_r
out = apr_brigade_create(r-pool, r-connection-bucket_alloc);
e = apr_bucket_eos_create(out-bucket_alloc);
APR_BRIGADE_INSERT_TAIL(out, e);
-rv = ap_pass_brigade(r-output_filters, out);
-if (rv != APR_SUCCESS) {
-if (rv != AP_FILTER_ERROR) {
-/* no way to know what type of error occurred */
-ap_log_rerror(APLOG_MARK, APLOG_DEBUG, rv, r,
- cache_quick_handler(%s): ap_pass_brigade returned
%i,
- cache-provider_name, rv);
-return HTTP_INTERNAL_SERVER_ERROR;
-}
-return rv;
-}
-return OK;
+return ap_pass_brigade_fchk(r, out,
+apr_psprintf(r-pool,
+ cache_quick_handler(%s):
ap_pass_brigade returned,
+ cache-provider_name));
}
This means we call apr_psprintf even if everything went well. That's far
from optimal. Maybe really make it into a macro, then the apr_psprintf
would only be executed on error?
/**
@@ -576,19 +568,10 @@ static int cache_handler(request_rec *r)
out = apr_brigade_create(r-pool, r-connection-bucket_alloc);
e = apr_bucket_eos_create(out-bucket_alloc);
APR_BRIGADE_INSERT_TAIL(out, e);
-rv = ap_pass_brigade(r-output_filters, out);
-if (rv != APR_SUCCESS) {
-if (rv != AP_FILTER_ERROR) {
-/* no way to know what type of error occurred */
-ap_log_rerror(APLOG_MARK, APLOG_DEBUG, rv, r,
- cache_handler(%s): ap_pass_brigade returned %i,
- cache-provider_name, rv);
-return HTTP_INTERNAL_SERVER_ERROR;
-}
-return rv;
-}
-
-return OK;
+return ap_pass_brigade_fchk(r, out,
+apr_psprintf(r-pool,
+ cache(%s): ap_pass_brigade
returned,
+ cache-provider_name));
}
Same as above
Re: client_ip vs remote_ip
On 11/23/2011 2:01 PM, Nick Kew wrote: 3. so wrowe's suggestion implies we EITHER divorce remote_ip from REMOTE_IP (confusing!) OR change the semantics of REMOTE_IP and potentially break thousands of CGI/etc apps. The later. We've already 'broken' thousands of CGI/etc apps throughout the world, as many customers of mine either use a remote_ip style solution or a much more trivial x-remote-ip header from their load balancer to reroute it. No reports of what grave ills this 'breakage' caused. Care to offer one, any one?
Re: svn commit: r1205423 - in /httpd/httpd/trunk/modules: cache/mod_cache.c mappers/mod_negotiation.c
On 23 Nov 2011, at 10:13 PM, Stefan Fritsch wrote: -return OK; +return ap_pass_brigade_fchk(r, out, +apr_psprintf(r-pool, + cache_quick_handler(%s): ap_pass_brigade returned, + cache-provider_name)); } This means we call apr_psprintf even if everything went well. That's far from optimal. Maybe really make it into a macro, then the apr_psprintf would only be executed on error? Or perhaps use varargs for the message? Regards, Graham --
Re: client_ip vs remote_ip
On 23 Nov 2011, at 10:01 PM, Nick Kew wrote: Um, are you responding to an altogether different point to the one I was making? Very possibly... 1. wrowe was suggesting changing the semantics of remote_ip in core. I interpreted wrowe's suggestion as simply making a name change on the variable to make a clearer distinction between c-remote_ip (IP address of httpd and upstream device, maybe a load balancer), and r-remote_ip (by default the exact same IP, unless mod_remoteip or mod_zeus / etc is configured, in which case it's now the IP of the client as seen by the load balancer, which wants to stay invisible). The semantics of the remote_ip is exactly the same in both cases - it contains the remote IP address of the client. When you add a load balancer in front of a set of httpds, the load balancer obscures the client's IP address, as it is now a man-in-the-middle. An administrator is now no longer able to use the standard httpd aaa stuff for authz, and loses the IP address in logging. For years load balancers have solved this problem using some means of revealing the client IP to the origin httpd (usually in a header), with a corresponding module like mod_remoteip or mod_zeus to override the IP address, but httpd has never had a clean way to allow this override to take place, as the IP address inside httpd is intimately wired into the connection, not the request. This fixes that, acknowledging that load balancers exist and properly allowing for them, without suffering hacks or leaks in our code. Regards, Graham --
Re: client_ip vs remote_ip
On 23 Nov 2011, at 18:22, Nick Kew wrote: But use of remote_ip and remote_addr goes further than that. Whoops! No it doesn't: it's just REMOTE_ADDR that features in CGI. Objection-in-principle to wrowe's suggestion withdrawn! How about, we make a clear break with possible confusion by dropping remote_ip altogether? It has wrowe's desired effect of forcing anyone who uses remote_ip to make a decision over what semantics are in fact needed. Appropriate Terminology Suggestion: Object ProtocolRemote Name -- -- request_rec HTTPClient client_ip conn_recTCP Peerpeer_ip -- Nick Kew
Re: client_ip vs remote_ip
On 24 Nov 2011, at 12:39 AM, Nick Kew wrote: Whoops! No it doesn't: it's just REMOTE_ADDR that features in CGI. Objection-in-principle to wrowe's suggestion withdrawn! How about, we make a clear break with possible confusion by dropping remote_ip altogether? It has wrowe's desired effect of forcing anyone who uses remote_ip to make a decision over what semantics are in fact needed. Appropriate Terminology Suggestion: ObjectProtocolRemote Name ---- request_rec HTTPClient client_ip conn_rec TCP Peerpeer_ip Sounds sensible, +1. Regards, Graham --
Re: client_ip vs remote_ip
On 11/23/2011 4:39 PM, Nick Kew wrote: Appropriate Terminology Suggestion: Object ProtocolRemote Name -- -- request_rec HTTPClient client_ip conn_recTCP Peerpeer_ip +1
Re: client_ip vs remote_ip
Am 24.11.2011 00:27, schrieb William A. Rowe Jr.: On 11/23/2011 4:39 PM, Nick Kew wrote: Appropriate Terminology Suggestion: Object Protocol Remote Name -- -- request_rec HTTP Client client_ip conn_rec TCP Peer peer_ip +1 +1 Regards Rüdiger
