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
Plüm wrote:
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 a
On 01/10/2006 02:11 PM, William A. Rowe, Jr. wrote:
Plüm wrote:
William A. Rowe, Jr. wrote:
Ruediger Pluem wrote:
[..cut..]
The straightforward thing is to close the client socket. Obviously it's
not that trivial; unix can reuse the same fd almost immediately. Perhaps
close the
Ruediger Pluem wrote:
Thanks to Jim for reviewing the patch. He detected one missed patch
and made some comments in the code clearer. The new patch list now:
Quick consideration;
Rather than look for HTTP_BAD_GATEWAY error bucket, we can actually
generalize the problem. ANY metadata bucket
William A. Rowe, Jr. wrote:
Ruediger Pluem wrote:
Thanks to Jim for reviewing the patch. He detected one missed patch
and made some comments in the code clearer. The new patch list now:
Quick consideration;
Rather than look for HTTP_BAD_GATEWAY error bucket, we can actually
generalize the
William A. Rowe, Jr. wrote:
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 a problem; and
therefore the result is a non-cacheable, broken response.
On 01/05/2006 08:59 PM, Ruediger Pluem wrote:
On 01/05/2006 01:51 PM, Ruediger Pluem wrote:
[..cut..]
I finally merged all the commits done to the trunk on this issue
Thanks to Jim for reviewing the patch. He detected one missed patch
and made some comments in the code clearer. The new
Still not sure why you are using a specific error detection
filter rather than the generic one in -trunk
On Jan 5, 2006, at 2:59 PM, Ruediger Pluem wrote:
@@ -146,13 +162,20 @@
* 2) the trailer
* 3) the end-of-chunked body CRLF
*
- * If there is no EOS
On Jan 6, 2006, at 1:47 PM, Jim Jagielski wrote:
Still not sure why you are using a specific error detection
filter rather than the generic one in -trunk
On Jan 5, 2006, at 2:59 PM, Ruediger Pluem wrote:
@@ -146,13 +162,20 @@
* 2) the trailer
* 3) the end-of-chunked
On 01/06/2006 07:47 PM, Jim Jagielski wrote:
Still not sure why you are using a specific error detection
filter rather than the generic one in -trunk
Arghh. Sorry I must have missed to include your patch that changed this.
Thanks for catching this. I will provide a new patch.
[..cut..]
+
On 01/06/2006 08:03 PM, Jim Jagielski wrote:
On Jan 6, 2006, at 1:47 PM, Jim Jagielski wrote:
[..cut..]
I should clarify that: when the comment says or yet the
code does an and then it causes undue confusion, even
if the 2 do sync up.
I think with the adjustments you made to the
Ruediger Pluem wrote:
I think with the adjustments you made to the comments it is now much
clearer what is done and this point is closed. Thanks for doing this.
np :)
--
===
Jim Jagielski [|] [EMAIL PROTECTED]
On 01/03/2006 06:15 PM, Jim Jagielski wrote:
On Jan 2, 2006, at 4:18 PM, Ruediger Pluem wrote:
1. Proposal
If a subrequest has a broken backend also set r-no_cache for the
main request
and ensure that the chunk filter does not sent the last chunk marker
in this case.
2. Proposal
On Thu, Jan 05, 2006 at 12:48:25PM +0100, Ruediger Pluem wrote:
But I remember myself that there had been casting issues in the past that
created compiler warnings especially with gcc 4. The patch below compiles
fine with my gcc 3.2.2 with -Wall. So if someone could give a comment
if
f-ctx
On 01/05/2006 12:58 PM, Joe Orton wrote:
On Thu, Jan 05, 2006 at 12:48:25PM +0100, Ruediger Pluem wrote:
[..cut..]
André's trick of using invented unique pointers by doing:
static char sentinel; (in global scope)
f-ctx = sentinel;
is neater and avoids the casting mess. (pick a
On Thursday 05 January 2006 11:58, Joe Orton wrote:
On Thu, Jan 05, 2006 at 12:48:25PM +0100, Ruediger Pluem wrote:
But I remember myself that there had been casting issues in the past that
created compiler warnings especially with gcc 4. The patch below compiles
fine with my gcc 3.2.2 with
On 01/05/2006 01:51 PM, Ruediger Pluem wrote:
[..cut..]
I finally merged all the commits done to the trunk on this issue
r354628
r354636
r357461
r357519
r365374
r366181
into one patch that works with 2.2.x. From my current point of view all
aspects of this issue should be considered by this
On 01/03/2006 03:52 AM, Justin Erenkrantz wrote:
On Mon, Jan 02, 2006 at 10:18:19PM +0100, Ruediger Pluem wrote:
[..cut..]
2. Proposal
If a subrequest has a broken backend do not sent the error bucket. Only
set r-no_cache to ensure that this subrequest response does not get
cached.
I
On 1/3/06, Ruediger Pluem [EMAIL PROTECTED] wrote:
2. Proposal
If a subrequest has a broken backend do not sent the error bucket. Only
set r-no_cache to ensure that this subrequest response does not get
cached.
I think we still need to ensure that an error bucket is sent too, right?
On Jan 2, 2006, at 4:18 PM, Ruediger Pluem wrote:
1. Proposal
If a subrequest has a broken backend also set r-no_cache for the
main request
and ensure that the chunk filter does not sent the last chunk
marker in this case.
2. Proposal
If a subrequest has a broken backend do not sent the
On 12/20/2005 10:14 PM, Ruediger Pluem wrote:
[..cut..]
But you pointed me to an interesting thing: If the main response is
T-E chunked and the backend error happened during the subrequest, the
chunked filter may sometimes add the last-chunk marker (if the brigade
containing the error
On Mon, Jan 02, 2006 at 10:18:19PM +0100, Ruediger Pluem wrote:
Before I take any further actions I would like to discuss the desired
behaviour
in the subrequest case:
1. Proposal
If a subrequest has a broken backend also set r-no_cache for the main
request and ensure that the chunk
In my random tests I discovered something:
We do not want to close connection to client if the proxy request is a
sub-request. We somehow have to flag an error in that case, but we do
not want to kill entire connection.
Just bit me in some qa stuff. I had to revert!
Ideas?
--
Brian Akins
On 12/20/2005 09:15 PM, Brian Akins wrote:
In my random tests I discovered something:
We do not want to close connection to client if the proxy request is a
sub-request. We somehow have to flag an error in that case, but we do
not want to kill entire connection.
I guess this is
On Dec 18, 2005, at 5:12 PM, Ruediger Pluem wrote:
On 12/18/2005 06:21 PM, Jim Jagielski wrote:
[..cut..]
My thoughts were something more like a ap_http_error_ofilter
which simply checks for the error bucket and does appropriate
things; something very general that the full http chain can
On 12/17/2005 11:22 PM, Ruediger Pluem wrote:
On 12/17/2005 06:30 PM, Jim Jagielski wrote:
[..cut..]
Even so, I say let's fold this into trunk as is, and
then work on abstracting it out.
Done as r357461.
Attached a patch that
- fixes the same problem for mod_proxy_ajp
- puts the
On 12/18/2005 02:39 PM, Ruediger Pluem wrote:
[..cut..]
Done as r357461.
Attached a patch that
- fixes the same problem for mod_proxy_ajp
- puts the common code in proxy_util
- fixes a little return code issue that is related to Justins original patch
in r354628
Forget about this
On 12/17/2005 06:30 PM, Jim Jagielski wrote:
[..cut..]
I still think that having this http specific error mode
hidden within the core output filter is misguided. Instead,
a specific http output filter is, imo, a better place.
How about the attached patch?
It moves the code into a
On Dec 18, 2005, at 10:59 AM, Ruediger Pluem wrote:
How about the attached patch?
It moves the code into a separate http protocol specific filter that
is only inserted if the request is a proxy request.
Of course it adds the effort of another loop over the brigade.
My thoughts were
On 12/18/2005 06:21 PM, Jim Jagielski wrote:
[..cut..]
My thoughts were something more like a ap_http_error_ofilter
which simply checks for the error bucket and does appropriate
things; something very general that the full http chain can
use.
Also an interesting idea. Do you already
On 12/16/2005 09:41 AM, Plüm wrote:
[..cut..]
Currently I am away from my development env. I hope I can post
a complete patch with all my ideas by tomorrow.
I worked out a new version of the patch. It is attached. I checked
it again with my jsp and it seems to work well. If nobody has
On Dec 17, 2005, at 11:32 AM, Ruediger Pluem wrote:
Index: server/core_filters.c
===
--- server/core_filters.c (Revision 357328)
+++ server/core_filters.c (Arbeitskopie)
@@ -315,8 +315,10 @@
On 12/17/2005 06:30 PM, Jim Jagielski wrote:
On Dec 17, 2005, at 11:32 AM, Ruediger Pluem wrote:
[..cut..]
I still think that having this http specific error mode
hidden within the core output filter is misguided. Instead,
a specific http output filter is, imo, a better place.
On Thu, Dec 15, 2005 at 10:12:57PM +0100, Ruediger Pluem wrote:
I think we have to simulate to the client what happened to us on the backend:
A broken connection.
I mostly agree.
However, Roy's veto is predicated on us not doing anything that would cause
a hypothetical (*duck*) Waka protocol
-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
On Dec 16, 2005, at 3:18 AM, Justin Erenkrantz wrote:
On Thu, Dec 15, 2005 at 10:12:57PM +0100, Ruediger Pluem wrote:
I think we have to simulate to the client what happened to us on
the backend:
A broken connection.
I mostly agree.
However, Roy's veto is predicated on us not doing
On Dec 16, 2005, at 3:18 AM, Justin Erenkrantz wrote:
So, to respect that -1, we need to keep that in mind that we only
force the
dropped connection somehow within the HTTP/1.1 logic. Or, have a
clear
path for a Waka filter chain to not drop the connection - by seeing
the
error bucket
Justin Erenkrantz wrote:
On Thu, Dec 15, 2005 at 10:12:57PM +0100, Ruediger Pluem wrote:
I think we have to simulate to the client what happened to us on the backend:
A broken connection.
I mostly agree.
However, Roy's veto is predicated on us not doing anything that would cause
a
-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
Plüm wrote:
This would give the client the
impression that the response had been correct and complete (provided
that the reponse was in chunked encoding). If the client is a proxy
this could lead to a cache poisoning.
THis is why I favor closing the connection to the client. It's simple
On 12/15/2005 09:35 PM, Brian Akins wrote:
Plüm wrote:
This would give the client the
impression that the response had been correct and complete (provided
that the reponse was in chunked encoding). If the client is a proxy
this could lead to a cache poisoning.
THis is why I favor
41 matches
Mail list logo
