On Dec 16, 2005, at 12:41 AM, Plüm, Rüdiger, VIS wrote:
I do not intend to do close the connection by myself. Currently it
will be closed because c-keepalive is set to AP_CONN_CLOSE
(a approach also suggested in Roys patch).
Right, the important bit is that the code managing the client
-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
Plüm wrote:
Stupid question: Can't we enforce at least this by setting
c-keepalive to AP_CONN_CLOSE. Of course this does not solve the problem
to make the remaining parts of the code aware of the bad gateway situation.
Probably, but other modules already check c-aborted. So it would be
best
-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
On Wed, Dec 07, 2005 at 10:21:10AM +0100, Plm, Rdiger, VIS wrote:
I would like to set the c-aborted in mod_proxy's proxy_handler after the
run_scheme_handler.
Reason:
1. We can define a clear interface for the scheme handlers here:
If the backend broke before you sent headers just
-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 c
On Wed, Dec 07, 2005 at 05:24:46PM +0100, Plm, Rdiger, VIS wrote:
Yes, I know. Maybe this is nitpicking, but my original understanding is that
c-aborted is set if the connection to the client has broken for whatever
external
reason on the network route between client and server, not if we
-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
On Dec 6, 2005, at 9:29 AM, Brian Akins wrote:
I have a serious issue. It seems that if something happens during
a proxy request after mod_http_proxy starts reading from the
backend server, no error is reported. (IE, see what happens when
ap_pass_brigade returns non success). The
Jim Jagielski wrote:
Hmmm. I haven't taken a look yet, but is seems to me that
only complete responses should be cached, not partial, and
as such we need some better mechanism in place for that
Not Cache-able, Could be Cache-able and To-Be-Cached
state tree.
From the best I can tell, the
Brian Akins wrote:
I have a serious issue. It seems that if something happens during a
proxy request after mod_http_proxy starts reading from the backend
server, no error is reported. (IE, see what happens when
ap_pass_brigade returns non success). The problem is that this
partial page may
Brian Akins wrote:
From the best I can tell, the issue is in the proxy code. When a
response gets truncated for whatever reason, it doesn't pass an error
along, so the filters never know that something bad happened.
From mod_proxy_http.c
in the function ap_proxy_http_process_response:
Paul Querna wrote:
Related issue:
http://issues.apache.org/bugzilla/show_bug.cgi?id=15866
I don't think its breaking the RFC to not-cache partial pages.
Yep. That's my issue:
This one doesn't have an easy solution. The problem is that mod_proxy
currently
has no way to tell mod_cache if a
Brian Akins wrote:
Jim Jagielski wrote:
Hmmm. I haven't taken a look yet, but is seems to me that
only complete responses should be cached, not partial, and
as such we need some better mechanism in place for that
Not Cache-able, Could be Cache-able and To-Be-Cached
state tree.
Brian Akins wrote:
Paul Querna wrote:
Related issue:
http://issues.apache.org/bugzilla/show_bug.cgi?id=15866
I don't think its breaking the RFC to not-cache partial pages.
Yep. That's my issue:
This one doesn't have an easy solution. The problem is that mod_proxy
currently
has no way to
Brian Akins wrote:
As a quick fix, could we not have proxy set r-status = HTTP_BAD_GATEWAY
or something and re-check in the cache before finalizing the store?
pseudo code:
in proxy_http
if(some proxy error) {
error_log(error during transit. forcing status change);
r-status =
On Tue, Dec 06, 2005 at 09:29:42AM -0500, Brian Akins wrote:
I have a serious issue. It seems that if something happens during a
proxy request after mod_http_proxy starts reading from the backend
server, no error is reported. (IE, see what happens when ap_pass_brigade
returns non
On Tue, Dec 06, 2005 at 12:07:32PM -0500, Brian Akins wrote:
in mod_cache in store_body check r-status on every bucket? This may
need to be in providers for now???
No. Changing the status after the first write will not matter. -- justin
Paul Querna wrote:
As a quick fix, could we not have proxy set r-status =
HTTP_BAD_GATEWAY or something and re-check in the cache before
finalizing the store?
Yes, and then remove the problem content and header file.
Since I do not use the stock mod_cache, I cannot really test it.
On Tue, Dec 06, 2005 at 12:10:44PM -0500, Brian Akins wrote:
Since I do not use the stock mod_cache, I cannot really test it.
However, I can try to get together a patch that changes r-status in
these cases. Is that acceptable? Will this screw up proxy_balancer or
is it out of the picture
Justin Erenkrantz wrote:
Our mod_cache will abort the response if the connection to the original
client is aborted for whatever reason. So, I'm doubtful the scenario you
describe would happen to our mod_cache. (See mod_disk_cache.c:1013.)
Cool. yep that would help me.
There *might* be a
On Tue, Dec 06, 2005 at 12:22:18PM -0500, Brian Akins wrote:
There *might* be a breakage if the server aborted it's half of the
connection partway through the response. I don't have the time to fully
look at the code, but there might be a code path that does so. -- justin
From what I can
Justin Erenkrantz wrote:
On Tue, Dec 06, 2005 at 12:22:18PM -0500, Brian Akins wrote:
There *might* be a breakage if the server aborted it's half of the
connection partway through the response. I don't have the time to fully
look at the code, but there might be a code path that does so. --
Justin Erenkrantz wrote:
After a bit more of thinking, the right thing to do would be to have
mod_proxy force a dropped connection to the client.
So, do we just need to set r-connection-aborted = 1 and core will take
care of it? If so, a patch should be trivial.
--
Brian Akins
Lead
--On December 6, 2005 2:02:02 PM -0500 Brian Akins [EMAIL PROTECTED]
wrote:
So, do we just need to set r-connection-aborted = 1 and core will take
care of it? If so, a patch should be trivial.
I think that's a side effect of being aborted. I think we need to first
abort the connection and
Justin Erenkrantz wrote:
I think that's a side effect of being aborted. I think we need to first
abort the connection and then set that field. =) -- justin
:) That's what I figured, just greping on aborted isn't showing
anything obvious...
--
Brian Akins
Lead Systems Engineer
CNN
Brian Akins wrote:
Justin Erenkrantz wrote:
I think that's a side effect of being aborted. I think we need to
first abort the connection and then set that field. =) -- justin
:) That's what I figured, just greping on aborted isn't showing
anything obvious...
Apparently that's how
Brian Akins wrote:
Justin Erenkrantz wrote:
After a bit more of thinking, the right thing to do would be to have
mod_proxy force a dropped connection to the client.
So, do we just need to set r-connection-aborted = 1 and core will take
care of it? If so, a patch should be trivial.
--On December 6, 2005 2:19:58 PM -0500 Brian Akins [EMAIL PROTECTED]
wrote:
Brian Akins wrote:
Justin Erenkrantz wrote:
After a bit more of thinking, the right thing to do would be to have
mod_proxy force a dropped connection to the client.
So, do we just need to set
Justin Erenkrantz wrote:
--On December 6, 2005 2:02:02 PM -0500 Brian Akins [EMAIL PROTECTED]
wrote:
So, do we just need to set r-connection-aborted = 1 and core will take
care of it? If so, a patch should be trivial.
I think that's a side effect of being aborted. I think we need
Justin Erenkrantz wrote:
I do think we need to fix mod_proxy_http to return an error.
So we need my patch and your patch, right? I'm a little medicated
today...
--
Brian Akins
Lead Systems Engineer
CNN Internet Technologies
--On December 6, 2005 3:01:28 PM -0500 Brian Akins [EMAIL PROTECTED]
wrote:
So we need my patch and your patch, right? I'm a little medicated
today...
I think so, yes. -- justin
Brian Akins wrote:
Justin Erenkrantz wrote:
I do think we need to fix mod_proxy_http to return an error.
So we need my patch and your patch, right? I'm a little medicated
today...
Yes, both.
--
===
Jim
Jim Jagielski wrote:
So we need my patch and your patch, right? I'm a little medicated
today...
Yes, both.
Can we vote on this? I guess we do it for HEAD then for 2.2.1 (or
something like that)?
Just want to make sure this will make into stock code. In the
meantime, I'll do a
--On December 6, 2005 3:10:44 PM -0500 Brian Akins [EMAIL PROTECTED]
wrote:
Just want to make sure this will make into stock code. In the
meantime, I'll do a local patch and test.
Test first, then if it works, we'll proceed with committing it to trunk and
then merging for 2.2.1. =) --
Brian Akins wrote:
Jim Jagielski wrote:
So we need my patch and your patch, right? I'm a little medicated
today...
Yes, both.
Can we vote on this? I guess we do it for HEAD then for 2.2.1 (or
something like that)?
Just want to make sure this will make into stock
Justin Erenkrantz wrote:
Test first, then if it works, we'll proceed with committing it to trunk
and then merging for 2.2.1. =) -- justin
Of course...
I'll have to work at a test case, because the buckets get passed before
I can abort. So c-aborted is happening after EOS has been sent, I
On Tue, Dec 06, 2005 at 03:26:00PM -0500, Jim Jagielski wrote:
Yes, please test. I'll also test here locally against stock
mod_cache (and pulling a cable between the test proxy and
origin server :) ). Then we fold into trunk, then immediately
propose to backport to httpd-2.2.
I'm already
Colm MacCarthaigh wrote:
I'm already testing, with some pretty big edge cases, sounds
good.
Also looks good from my side. I'll do some more testing. We, as you
can imagine, get tons of edge cases.
--
Brian Akins
Lead Systems Engineer
CNN Internet Technologies
On Dec 6, 2005, at 9:38 AM, Justin Erenkrantz wrote:
On Tue, Dec 06, 2005 at 12:22:18PM -0500, Brian Akins wrote:
There *might* be a breakage if the server aborted it's half of the
connection partway through the response. I don't have the time
to fully
look at the code, but there might be a
Roy T. Fielding wrote:
That would depend on the current state of the proxy's response to
the client, since it may have not even sent the status code on the
wire. If not, then marking the connection as aborted will just make
it look like the proxy is broken, so we should send a 503 error
Brian Akins wrote:
Colm MacCarthaigh wrote:
I'm already testing, with some pretty big edge cases, sounds
good.
Also looks good from my side. I'll do some more testing. We, as you
can imagine, get tons of edge cases.
I likely can't approach some of the edge cases you can, but
On Dec 6, 2005, at 12:45 PM, Brian Akins wrote:
That would work, I suppose, but wouldn't the client get the same
impression proxy is broken? I generally only deal with reverse
proxies, so if origin is broken, whole site is broken...
Sorry, reverse proxy is not a proxy -- it is a gateway.
Jim Jagielski wrote:
As Roy indicates, we may need to tweak this to return a 503
depending on the actual state of the proxied connection/response,
but this is still looking v good.
Can we vote on it as is? It fixes the problem, we can make it pretty
later. Of course, if someone has a
Roy T. Fielding wrote:
Sorry, reverse proxy is not a proxy -- it is a gateway.
Sure it is. but that's semantics and any further discussion of that
would be futile.
You are right that it won't make a difference in the gateway case,
though from a software design perspective,
--On December 6, 2005 3:57:37 PM -0500 Brian Akins [EMAIL PROTECTED]
wrote:
Can we vote on it as is? It fixes the problem, we can make it pretty
later. Of course, if someone has a better solution right now...
We aren't ready to do 2.2.1 just yet, so there's no need to particularly
rush
Justin Erenkrantz wrote:
We aren't ready to do 2.2.1 just yet
Sure we are, if someone steps up to RM a new release, and it gets the votes
to go out the door.
Bill
William A. Rowe, Jr. wrote:
Justin Erenkrantz wrote:
We aren't ready to do 2.2.1 just yet
Sure we are, if someone steps up to RM a new release, and it gets the votes
to go out the door.
Well, there's an issue with the proxy balancer that needs
to be addressed as well 1st, imo.
I'm
On 12/06/2005 10:53 PM, Jim Jagielski wrote:
[..cut..]
Well, there's an issue with the proxy balancer that needs
to be addressed as well 1st, imo.
Could you please give my memory a small hint what this issue is?
Regards
Rüdiger
Ruediger Pluem wrote:
On 12/06/2005 10:53 PM, Jim Jagielski wrote:
[..cut..]
Well, there's an issue with the proxy balancer that needs
to be addressed as well 1st, imo.
Could you please give my memory a small hint what this issue is?
Keepalives and multiple workers
--
On 12/07/2005 12:10 AM, Jim Jagielski wrote:
[..cut..]
Well, there's an issue with the proxy balancer that needs
to be addressed as well 1st, imo.
Could you please give my memory a small hint what this issue is?
Keepalives and multiple workers
Sorry, that I don't get it
--On December 6, 2005 3:57:37 PM -0500 Brian Akins [EMAIL PROTECTED]
wrote:
Can we vote on it as is? It fixes the problem, we can make it pretty
later. Of course, if someone has a better solution right now...
I just reproduced the problem with the following setup:
1) On 8080, httpd trunk /
On 12/07/2005 01:32 AM, Justin Erenkrantz wrote:
[..cut..]
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
--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
54 matches
Mail list logo
