-Ursprüngliche Nachricht-
Von: Rian Hunter
Is there a kernel accept filter enabled?
No, it is a default clean install. Are you suggesting that for me to
get the behavior I want that there should be one enabled?
No, but on Linux I think TCP_DEFER_ACCEPT is set by default
-Ursprüngliche Nachricht-
Von: Brian Akins
Proxy sents up an error_bucket with HTTP_BAD_GATEWAY if the
connection
to the backend broke in the middle.
So should every modules that reads the brigade check for an error
bucket?
yes
It does not appear that any of the cache
-Ursprüngliche Nachricht-
Von: Bart van der Schans
Hi,
The ProxyErrorOverride On setting is correctly catching the errors
from the (reverse) proxied server. Only, it overrides too much IMHO.
Right now it overrides anything that's not in the 2xx range,
but I think
it should
-Ursprüngliche Nachricht-
Von: Brian Akins
It looks like I'm getting some wierdness with http_proxy. it is not
returning any error, but is giving back a 0 length bucket from
apr_bucket_read when it should have some length.
This description requires some clarification IMO. Is
-Ursprüngliche Nachricht-
Von: Paul Querna
To resolve the problems we have with calling apu_version from
httpd, we
have three main options:
[ ] Remove the new code that outputted the versions.
[X] Make the code only present on systems that didn't have a
broken build.
[ ]
-Ursprüngliche Nachricht-
Von: Jim Jagielski
+file_cache_errorcleanup(dobj, r);
+return APR_EGENERAL;
+}
Why don't we return rv ?
Because we also return APR_EGENERAL in the cases below. I think the behaviour
should be consistent. So if we
-Ursprüngliche Nachricht-
Von: Jim Jagielski
That seem to be the case when we have a general error. In other
places where we have a valid 'rv', we tend to return that.
Look at file_cache_recall_mydata() for example...
In the above, I think the return status may be useful,
-Ursprüngliche Nachricht-
Von: Jim Jagielski
to do here.
Ok, but this actually works already without your patch.
I never even bothered to check... Brian's initial
Email said that it didn't. Are you saying that his Email
is wrong and that balancers defined in the main
-Ursprüngliche Nachricht-
Von: Jim Jagielski
I want to be able to use same balancer in multiple vhosts.
This is actually that way by design, iirc. I've no
real issues with it being Vhost specific or inheritable.
So if others think it's worthwhile having the above
-Ursprüngliche Nachricht-
von Garrett Rooney
Sticking per-backend info like ajp_flush_wait into the worker
object and the code to configure it in mod_proxy.c itself
seems very wrong to me. There should be a per-backend
contect pointer to hold per-backend information, and the
-Ursprüngliche Nachricht-
Von: Jim Jagielski
Agreed. I'm +1 for making it non-AJP specific to handle
the other issues. But I wanted it to crawl before walk :)
Thats a very good idea :-).
Regards
Rüdiger
-Ursprüngliche Nachricht-
Von: Justin Erenkrantz
Until the protocol is fixed, we should do the right thing -
and that means we shouldn't ever allow the entire response to
be spooled in memory. -- justin
Actually we do not do this. The original code did this which lead to a
-Ursprüngliche Nachricht-
Von: Mladen Turk
First: I am the author.
Hi,
I would love that we remove the FLUSHING_BANDAID from the code
because it concept breaks the AJP protocol specification.
I do not understand how this breaks the spec. There might be reasons
to handle
-Ursprüngliche Nachricht-
Von: William A. Rowe, Jr.
Stop bitching about a 10 year old spec. It's trivial, use a
modern browser (beyond today - none exist yet) that can do
Connection-Upgrade and agree about the text of the headers
before the ssl handshake is performed. The
As this is public information and in everybodys interest I forward this.
-Ursprüngliche Nachricht-
Von: Yusuf Goolamabbas
Or wait for RFC3546 (ftp://ftp.rfc-editor.org/in-notes/rfc3546.txt)
be implemented in the browsers and servers. IE 7 beta is said to
support it and upcoming
-Ursprüngliche Nachricht-
Von: Paul Querna
I didn't know that openssl 0.9.9 is likely to include support for SNI.
If it does, that is great.
I would be happy to write the code for mod_ssl to also support SNI.
See also
-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED]
Isn't that very unreliable?
Why should Unix domain sockets be unreliable?
Yeah, that's my question as well. Quite a few people seem to
use them...
Maybe he is working on an upatched Solaris 10 ;-).
Regards
Rüdiger
-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED]
We actually have a way to do that, it's the close_on_recycle flag, and
I had to turn it on in order to get anything approaching reliability
for fastcgi. The problem with just using that is that without some
coordination between
von Garrett Rooney
Exactly, the pool of available backends needs to be managed globally,
which we don't currently have and it's not clear if that ability would
be useful outside of fastcgi.
But as connection pools are per worker and not per cluster
this problem should also appear in the
-Ursprüngliche Nachricht-
Von: Graham Leggett
Is there a mechanism within v2.2.0 to put resource limits onto CGI
programs (maximum running simultaneously, longest time in seconds to
run, that sort of thing)?
What about
RLimitCPU
RLimitMEM
RLimitNPROC
But I remember that they
-Ursprüngliche Nachricht-
Von: Graham Leggett
Hmmm... the docs explain both a soft limit and a maximum
limit, but
doesn't describe the difference between the two.
It is the same thing as the soft and hard limit on Unix OS'es.
But I remember that they do not work either
Von: Im Auftrag von Justin Erenkrantz
Gesendet: Montag, 27. Februar 2006 22:37
BTW: Justins idea to exchange the transient buckets with heap buckets was
also correct
as it seems that the transient buckets might get overwritten in some
situations.
So Justin could you please commit
-Ursprüngliche Nachricht-
Von:
Serf's mailing list is at:
http://mailman.webdav.org/mailman/listinfo/serf-dev/
(You'll find some familiar faces posting there. *duck*)
Thanks for the hints. I see it is a low traffic mailing list :-).
I hope to find time to have a look into
-Ursprüngliche Nachricht-
Von: Joe Orton
The regression test runs last night had between zero and
three failures
in t/ssl/proxy.t in various builds (timing dependent, I guess); the
build which had three failures was:
So that seems to be related to the other issue we
-Ursprüngliche Nachricht-
Von: Joe Orton
New Revision: 378032
URL: http://svn.apache.org/viewcvs?rev=378032view=rev
Log:
*) mod_proxy: Fix KeepAlives not being allowed and set to
backend servers. PR38602. [Ruediger Pluem, Jim Jagielski]
Also, document previous
-Ursprüngliche Nachricht-
Von: Joe Orton
http://mail-archives.apache.org/mod_mbox/httpd-dev/200602.mbox
/ajax/[EMAIL PROTECTED]
this is really weird. Maybe another change that happened after r378032?
Maybe Jim's build didn't include mod_ssl? r378032 is the most recent
change
-Ursprüngliche Nachricht-
Von: Joe Orton
Could you please give the following patch a try?
That fixed most of the failures, there are still two left:
OK. That gives a better idea what possibly goes wrong.
t/ssl/proxyok 61/172# Failed test 62 in t/ssl/proxy.t at line 112
-Ursprüngliche Nachricht-
Von: Jim Jagielski
Jim Jagielski wrote:
Hmmm... Possibly SSL requires close_on_recycle. Or, at
least, using that flag as required for SSL.
I don't have time to explain in more detail, but the more
I look over the old way, it was to maintain
-Ursprüngliche Nachricht-
Von: Jim Jagielski
term. Might be easier if we have a http / https client
library as part
of httpd or apr-util.
This only helps http, not ajp/fcgi or other protocols.
True, but ajp already does not use the fake conn_rec / request_rec stuff.
Instead
-Ursprüngliche Nachricht-
Von: Jim Jagielski
No regressions...
Now that this has been passed successfully, do you see need for
any further discussion / changes before I commit it or should
I commit to the trunk and we continue our further changes / discussions
there?
Regards
-Ursprüngliche Nachricht-
Von: Jim Jagielski
I vote to commit and use that as the continue point for
more development :)
Excellent. I will do so tonight German time. Currently I am away from my
development env as you may have noticed from my nicely formated
Outlook mails :-).
-Ursprüngliche Nachricht-
Von: Jim Jagielski
On Feb 13, 2006, at 6:25 PM, Ruediger Pluem wrote:
Although it's not really documented anyplace, it really is
good practice for people who submit large changes to run
That seems a reasonable good idea.
them through the
-Ursprüngliche Nachricht-
Von: Jim Jagielski
I'm currently trying to trace through exactly how the code is
trying to pool connections. Of course, we're only using
reslist if we're a threaded MPM...
Really? I thought APR_HAS_THREADS is set when the OS supports threads.
I thought
-Ursprüngliche Nachricht-
Von: Jim Jagielski
Yeah, but we check to see if we're 1 thread, so in prefork,
we drop to single connection workers.
Which makes sense to me. Why have more than one connection per worker
on a prefork processes that can only handle one request at a
-Ursprüngliche Nachricht-
Von: Jim Jagielski
Off the top of my head, I have no idea why we even have lb_score
rather than just using proxy_worker_stat as we should.
This is easy to fix except for the fact that ap_get_scoreboard_lb()
is AP_DECLARE... Of course, adjusting in
-Ursprüngliche Nachricht-
Von: Jim Jagielski
quite right, since it means that the *shared* data
has been initialized, but that this worker may not
have been (if you catch my drift). Furthermore,
this means that the -cp stuff isn't being
fully init'ed...
Yep, see
-Ursprüngliche Nachricht-
Von: Jim Jagielski
That was the reason I added the 'context' struct member, to
allow for some reasonable extensions without adjusting the
actual API. :)
Yes, but it is not possible to share this data over processes
easily as it is only a pointer.
-Ursprüngliche Nachricht-
Von: Jim Jagielski
Yes, but it is not possible to share this data over
processes easily
as it is only a pointer.
But it could be a pointer to a shared memory segment :)
Yes of course, but I have to write more code to manage this
than for an
-Ursprüngliche Nachricht-
Von: Graham Leggett
Gregor J. Rothfuss wrote:
i am trying to use mod_proxy_balancer with a backend that is in turn
using name-based virtual hosts.
it seems that mod_proxy_balancer doesn't honor
ProxyPreserveHost (both
2.2.0 and trunk), and
-Ursprüngliche Nachricht-
Von: Gregor J. Rothfuss
hi,
i am trying to use mod_proxy_balancer with a backend that is in turn
using name-based virtual hosts.
it seems that mod_proxy_balancer doesn't honor
ProxyPreserveHost (both
2.2.0 and trunk), and does not send the
-Ursprüngliche Nachricht-
Von: Alan Gutierrez
The proposed solution is to poll for chunks using
non-blocking I/O. When the socket returns EAGAIN, the 8K
buffer is flushed, and the socket is read with blocking I/O.
Thats the way the code is already designed in 2.2.x.
-Ursprüngliche Nachricht-
Von: Matthieu Estrade
The reverse proxy read a brigade, then forward it to the
client. It should not
buffer the response but forward block of data. Maybe it's
because of deflate
mod_deflate buffers definitely. You need to turn it off for
such pages
-Ursprüngliche Nachricht-
Von: CASTELLE Thomas .
Anyway, even if the Apache timeout is increased, Firewalls or browsers don't
like idle TCP/IP session either... without speaking of the users ;-)
Regarding my problem, I tried to disable every modules (except mod_proxy of
course),
-Ursprüngliche Nachricht-
Von: Robby Pedrica
Hi Rudiger,
I've applied patches and recompiled. My results are as follows:
1. apache starts up with the member 'b' disabled now
2. if I shutdown the working member 'a' httpd, then manager shows the change
only when you try and
-Ursprüngliche Nachricht-
Von: Robby Pedrica
Thanks Rudiger,
I've set redirect and route values - not sure if these are correct:
Proxy balancer://mycluster
BalancerMember http://192.168.4.2:80 redirect=1
BalancerMember http://192.168.4.3:80 route=1 status=D
/Proxy
I'm
-Ursprüngliche Nachricht-
Von: Plüm, Rüdiger,
This only works with session stickyness. So
ProxyPass / balancer://mycluster stickysession=SESSION_COOKIE
Proxy balancer://mycluster BalancerMember
http://192.168.4.2:80 route=a redirect=b BalancerMember
http://192.168.4.3:80
-Ursprüngliche Nachricht-
Von: Jim Jagielski
I think we're in agreement that the current failover does
not work as it should with HTTP, and is quite
cumbersome to get it to work. :)
Apart from the fact that it currently does not even work without
patches :-).
So I am keen on
-Ursprüngliche Nachricht-
Von: Jim Jagielski
Why the breaks? Certainly we still want to continue the
for loop even if we see a valid setting. For example,
to set a worker in DISABLED and STOPPED mode.
1. Currently there is no clear separation letter.
2. Setting status=disabled
-Ursprüngliche Nachricht-
Von: Jim Jagielski
On Feb 1, 2006, at 9:02 AM, Plüm, Rüdiger, VIS wrote:
So I am keen on feedback by Robby. I hope to find time to
commit these
changes to the trunk tonight, so that it works at least in the
cumbersome way :-).
I will cut
-Ursprüngliche Nachricht-
Von: Robby Pedrica
Gesendet: Montag, 30. Januar 2006 09:27
Betreff: proxy failover/load balance
wrt information provided by Mladen Turk, Jim Jagielski and Andreas Wieczorek:
I'm having issues when using mod_proxy/mod_proxy_balancer and it appears
these
-Ursprüngliche Nachricht-
Von: Noranis Aris
This is a user specific question. Please post it
to users@httpd.apache.org
Regards
Rüdiger
-Ursprüngliche Nachricht-
Von: Laurent Perez
Sorry to up this thread again, but another wrong behaviour
appeared after I switched to 2.2 (source from
http://apache.crihan.fr/dist/httpd/httpd-2.2.0.tar.gz) :-(
The varying now works fine, with the .vary folder filled with
-Ursprüngliche Nachricht-
Von: Ian Holsman
Brian Akins wrote:
This is a rather nasty patch (sorry). Basically, it changes the way
arrays and tables are stored on disk. This allows us to do a much
cleaner and quicker read_array and read_table. It cuts down
-Ursprüngliche Nachricht-
Von: Jim Jagielski
[..cut..]
A sort of warm standby is something that I had planned to
work into the balancer code post 2.2.1.
+1
AFAIK local_worker_only mentioned below does not exist any longer
in recent versions of mod_jk, but the recent version
-Ursprüngliche Nachricht-
Von: Mladen Turk
Like said earlier.
Hot standby already works with mod_proxy balancer.
The 'hot standby' BalancerMember must be initially
'disabled'. Other members must have 'redirect' option set to
Maybe it is just me being blind. But I haven't
-Ursprüngliche Nachricht-
Von: Jim Jagielski
Maybe it is just me being blind. But I haven't found in the =
documentation how to disable a BalancerMember. Is this a 'hidden'
feature? :-)
The balancer-manager does that... well, let's the admin do that.
+1
Otherwise it
-Ursprüngliche Nachricht-
Von: Justin Erenkrantz
What SVN rev are we talking about here? If it's the Solaris mod_cgid
thread check in modules/generators/config.m4, then yes, I
believe I have a
+1 to 2.0.x; if not, well, here you go: +1. =) -- justin
I am talking about
-Ursprüngliche Nachricht-
Von: Nick Kew
That's just about what I had in mind. But I'd hesitate to
use it without knowing whether someone had a reason for
putting it at the end of the function originally. It would
affect the semantics of post_read_request, but is that fixing
-Ursprüngliche Nachricht-
Von: Nick Kew
[..cut..]
That's the same bug and fix as PR#37790!
Which leads me to wonder, is there some good reason not to
insert the input filter unconditionally somewhere earlier in
request_post_read? As it stands, it looks as if your fix has
-Ursprüngliche Nachricht-
Von: Sierk Bornemann
[..cut..]
--
APR_BRIGADE_FOREACH does not longer exist, so there must be a
short fix
reflecting this.
The macro APR_BRIGADE_FOREACH is marked deprecated in apr-util 0.9.x
which is used by Apache 2.0.x for quite a long
William A. Rowe, Jr. wrote:
Ruediger Pluem wrote:
[..cut..]
Quick consideration;
Rather than look for HTTP_BAD_GATEWAY error bucket, we can actually
generalize the problem. ANY metadata bucket that isn't
recognized and
handled by an intermediate filter probably indiciates
-Ursprüngliche Nachricht-
Von: Justin Erenkrantz
Gesendet: Freitag, 16. Dezember 2005 09:19
An: dev@httpd.apache.org
Betreff: Re: AW: AW: 2.2 mod_http_proxy and partial pages
On Thu, Dec 15, 2005 at 10:12:57PM +0100, Ruediger Pluem wrote:
I think we have to simulate to the
-Ursprüngliche Nachricht-
Von: Brad Nicholes
Gesendet: Donnerstag, 15. Dezember 2005 16:39
An:
Betreff: Re: [PATCH] Rename to Apache D
You're not really serious about this are you? It is a
little premature to rename something to 'd' that is still
very much 'httpd'.
-Ursprüngliche Nachricht-
Von: Jim Jagielski
Gesendet: Donnerstag, 15. Dezember 2005 17:02
An: dev@httpd.apache.org
Betreff: Re: AW: 2.2 mod_http_proxy and partial pages
{..cut..]
Sorry, but I think I have to disagree.
There is nothing that can be handled anymore since
-Ursprüngliche Nachricht-
Von: Justin Erenkrantz
Gesendet: Freitag, 9. Dezember 2005 06:22
An: dev@httpd.apache.org
Betreff: Re: AW: 2.2 mod_http_proxy and partial pages
[..cut..]
Even with an EOS bucket, how will we indicate that the
connection should be aborted? (i.e.
-On December 7, 2005 2:00:19 AM +0100 Ruediger Pluem [EMAIL PROTECTED]
wrote:
The patches to mod_proxy_http we identified here on list do indeed work
and are in as r354628.
Sorry for stepping in that late into the discussion, but wouldn't it be
better to fix that after the return from
-Ursprüngliche Nachricht-
Von: Justin Erenkrantz
Gesendet: Mittwoch, 7. Dezember 2005 17:08
An: dev@httpd.apache.org
Betreff: Re: 2.2 mod_http_proxy and partial pages
[..cut..]
Feel free to commit a patch. =)
I will do so :).
2. I am not 100% percent happy with the
-Ursprüngliche Nachricht-
Von: Justin Erenkrantz
Gesendet: Mittwoch, 7. Dezember 2005 17:30
An: dev@httpd.apache.org
Betreff: Re: 2.2 mod_http_proxy and partial pages
On Wed, Dec 07, 2005 at 05:24:46PM +0100, Plm, Rdiger, VIS wrote:
[..cut..]
Nope, that's the flag we set
-Ursprüngliche Nachricht-
Von: Jim Jagielski
Gesendet: Mittwoch, 7. Dezember 2005 17:43
An: Justin Erenkrantz
Cc: dev@httpd.apache.org; [EMAIL PROTECTED]
Betreff: Re: svn commit: r354779 - /httpd/httpd/branches/2.2.x/STATUS
Sure... Right now, there appears to be some questions
-Ursprüngliche Nachricht-
Von: Roy T. Fielding
Gesendet: Donnerstag, 8. Dezember 2005 03:17
[..cut..]
Ok. Then I withdraw my objections against the setting of
c-aborted. I
just understood its purpose wrong. Thanks for clarification.
No, you understood its purpose
[..cut..]
Thanks! I've committed this in r231486, r231487, and r231488. I re-split
them up to make it easier for people to review the commits.
However, there remains an issue in mod_disk_cache's remove_url: I don't think
it properly handles removing the Vary condition files. I went ahead
--On August 8, 2005 1:25:46 PM +0100 Colm MacCarthaigh [EMAIL PROTECTED]
wrote:
O.k., I've merged our two patches, but I've changed a few things, tell
me if there's anothing you think is wrong;
Would you mind writing up a log message for this patch?
I've lost track of what it's supposed to
72 matches
Mail list logo
