[ http://issues.apache.org/jira/browse/MODPYTHON-14?page=all ]
Graham Dumpleton resolved MODPYTHON-14:
---
Fix Version: 3.1.3
Resolution: Fixed
Returning nothing from mod_python.publisher (2.7.10) causes 500 error text to
be appended.
[ http://issues.apache.org/jira/browse/MODPYTHON-14?page=all ]
Graham Dumpleton closed MODPYTHON-14:
-
Returning nothing from mod_python.publisher (2.7.10) causes 500 error text to
be appended.
[ http://issues.apache.org/jira/browse/MODPYTHON-56?page=all ]
Graham Dumpleton resolved MODPYTHON-56:
---
Resolution: Incomplete
This problem may also be because of problems with PythonPath such as described
in MODPYTHON-114. The lack of a way
[ http://issues.apache.org/jira/browse/MODPYTHON-71?page=all ]
Graham Dumpleton resolved MODPYTHON-71:
---
Resolution: Invalid
Further checking did indeed find that a handler should not truncate output for
HEAD. Doing so can actually interfere
[ http://issues.apache.org/jira/browse/MODPYTHON-71?page=all ]
Graham Dumpleton closed MODPYTHON-71:
-
Support the HEAD method properly
Key: MODPYTHON-71
URL:
[ http://issues.apache.org/jira/browse/MODPYTHON-56?page=all ]
Graham Dumpleton closed MODPYTHON-56:
-
Error 404 importing module from the same folder
---
Key: MODPYTHON-56
URL:
[ http://issues.apache.org/jira/browse/MODPYTHON-76?page=all ]
Work on MODPYTHON-76 started by Graham Dumpleton
input filter hangs in combination with mod_proxy
Key: MODPYTHON-76
URL:
[ http://issues.apache.org/jira/browse/MODPYTHON-27?page=all ]
Graham Dumpleton reassigned MODPYTHON-27:
-
Assign To: Graham Dumpleton
mod_python.publisher authentication
---
Key: MODPYTHON-27
[ http://issues.apache.org/jira/browse/MODPYTHON-27?page=all ]
Work on MODPYTHON-27 started by Graham Dumpleton
mod_python.publisher authentication
---
Key: MODPYTHON-27
URL: http://issues.apache.org/jira/browse/MODPYTHON-27
[ http://issues.apache.org/jira/browse/MODPYTHON-47?page=all ]
Work on MODPYTHON-47 started by Graham Dumpleton
Digest Authorization header causes bad request error.
-
Key: MODPYTHON-47
URL:
[ http://issues.apache.org/jira/browse/MODPYTHON-47?page=all ]
Graham Dumpleton updated MODPYTHON-47:
--
Attachment: MP47_20060307_grahamd_1.diff
Attached MP47_20060307_grahamd_1.diff with proposed patch. Feedback on this
one appreciated.
Digest
Joe Schaefer [EMAIL PROTECTED] writes:
Joe Schaefer [EMAIL PROTECTED] writes:
Here's a patch against the 2.2.x branch of httpd (you need to
apply the svn:externals properties manually). With it I can
build mod_apreq (no 2) statically or dynamically. Haven't tested
it at all yet tho.
-Original Message-
From: Daniel Rogers [mailto:[EMAIL PROTECTED]
Sent: Montag, 6. März 2006 19:01
The end user sees only port 443. No worries about weird port numbers.
Ok - I read the post and I agree your solution doesn't rely on using a
non-standard port externally. I was
Hi,
I would love that we remove the FLUSHING_BANDAID from the code
because it concept breaks the AJP protocol specification.
Instead FLUSHING_BANDAID I propose that we introduce a new
directive 'flush=on' that would behave like the most recent
mod_jk directive 'JkOptions +FlushPackets'.
The
I am not concerned with the form of this feature's delivery -- as long
as it is well documented.
I will say that having an explicit flush that flushes up through the web
server is absolutely critical to certain use cases. Lack of this
functionality one way or another will break our apps.
-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
As someone who depends on such flushing I'd echo that we don't need
flushing after every AJP packet -- just when we explicitly call flush().
Plm wrote:
-Ursprngliche Nachricht-
Von: Mladen Turk
First: I am the author.
Hi,
I would love that we
Plüm wrote:
First: I am the author.
Cool. Did someone ever told you to that you
need to fix your mail client ;).
I hate your AW:AW:AW...
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
On Sun, Mar 05, 2006 at 03:06:09PM -0800, Garrett Rooney wrote:
First of all, mod_proxy_balancer really assumes that you can make
multiple connections to back end fastcgi processes at once. This may
be true for some things that speak fastcgi (python programs that use
flup to do it sure look
On 3/7/06, Brian Candler [EMAIL PROTECTED] wrote:
I'm not sure what you mean there, in particular what you mean by 'assumes
that you can make multiple connections to back end fastcgi processes'
What I'm familiar with is apache 1.x with mod_fcgi. In that case, the
typical fastcgi program does
Plüm wrote:
As a summary from your side I see:
1. Extend AJP protocol [The desired target from my view].
Desireable to line up with, say, Tomcat6. But this really doesn't help the
installed base of Tomcat 4/5, right? With the evolving spec, progressive
java prereqs, it's pretty easy for
Mladen Turk wrote:
William A. Rowe, Jr. wrote:
support should be default (flushed) with the -option- to optimize for
those
apps who aren't harmed by streaming.
Right. We have two options, either to flush on each packet,
that BTW might or might not reflect the user 'out.flush();'
or keep
I would suggest that the bandaid code no longer be
compile time but rather runtime, using a
force-flush=true param to the AJP worker.
I agree that the current default may be right for
some, but majorly bad for others :) :)
On Mar 7, 2006, at 2:58 PM, Mladen Turk wrote:
William A. Rowe, Jr.
On 03/07/2006 07:19 PM, Mladen Turk wrote:
Plüm wrote:
First: I am the author.
Cool. Did someone ever told you to that you
need to fix your mail client ;).
I hate your AW:AW:AW...
Sorry I forgot to remove. Stupid Outlook at work. I don't use
it outside as you may notice.
I
Jim Jagielski wrote:
I would suggest that the bandaid code no longer be
compile time but rather runtime, using a
force-flush=true param to the AJP worker.
I agree that the current default may be right for
some, but majorly bad for others :) :)
Correct :)
I mean, now we have a flush no mater
On 03/07/2006 08:58 PM, Mladen Turk wrote:
William A. Rowe, Jr. wrote:
The current implementation breaks a simple timeout write:
out.write(Hello);
Thread.sleep(2000);
out.write(World);
It will send the 'Hello', but only after additional thread
finishes and times out.
Given the above
William A. Rowe, Jr. wrote:
For the benefit of folks here and not on mod_jk...
Check out jk_ajp_common.c in tomcat-5.5-connectors/jk/native/common
where whether the flush is forced for each JK_AJP13_SEND_BODY_CHUNK
is controlled by the FlushPackets. Also note how we vary
behavior at
On 03/07/2006 09:15 PM, Jim Jagielski wrote:
I would suggest that the bandaid code no longer be
compile time but rather runtime, using a
force-flush=true param to the AJP worker.
Just for clarification: What is your exact purpose?
1. Use the poll method of the bandaid, but make it possible
On 03/07/2006 10:10 PM, Jim Jagielski wrote:
William A. Rowe, Jr. wrote:
For the benefit of folks here and not on mod_jk...
Check out jk_ajp_common.c in tomcat-5.5-connectors/jk/native/common
where whether the flush is forced for each JK_AJP13_SEND_BODY_CHUNK
is controlled by the
On 3/7/06, Jim Jagielski [EMAIL PROTECTED] wrote:
I would suggest that the bandaid code no longer be
compile time but rather runtime, using a
force-flush=true param to the AJP worker.
I'd prefer that we not defer this decision to the users - we should
either enable it or don't. But, most
[ http://issues.apache.org/jira/browse/MODPYTHON-107?page=all ]
Work on MODPYTHON-107 started by Graham Dumpleton
mod_python.publisher shouldn't flush result when written.
-
Key: MODPYTHON-107
URL:
[ http://issues.apache.org/jira/browse/MODPYTHON-107?page=all ]
Graham Dumpleton reassigned MODPYTHON-107:
--
Assign To: Graham Dumpleton
mod_python.publisher shouldn't flush result when written.
Justin Erenkrantz wrote:
Without FLUSHING_BANDAID, httpd will queue up the data when Tomcat
doesn't plan on writing any more. That's bad.
Unless/until AJP has a protocol revision, I think the code should stay
and be enabled by default. The only 'right' fix is to correct the
buggy underlying
Justin Erenkrantz wrote:
On 3/7/06, Jim Jagielski [EMAIL PROTECTED] wrote:
I would suggest that the bandaid code no longer be
compile time but rather runtime, using a
force-flush=true param to the AJP worker.
I'd prefer that we not defer this decision to the users - we should
either enable
Paul Querna wrote:
Justin Erenkrantz wrote:
Without FLUSHING_BANDAID, httpd will queue up the data when Tomcat
doesn't plan on writing any more. That's bad.
Unless/until AJP has a protocol revision, I think the code should stay
and be enabled by default. The only 'right' fix is to correct
On 03/07/2006 11:43 PM, Justin Erenkrantz wrote:
On 3/7/06, Jim Jagielski [EMAIL PROTECTED] wrote:
I would suggest that the bandaid code no longer be
compile time but rather runtime, using a
force-flush=true param to the AJP worker.
I'd prefer that we not defer this decision to the users
Ruediger Pluem wrote:
OTH I guess we still have to convince some people to switch from mod_jk
to mod_proxy_ajp. So I guess having a similar behaviour in mod_proxy_ajp
as in mod_jk will ease this. Default for mod_jk is: No flushing.
Then I'm confused, I thought this was reverted in the current
Quoting Bojan Smojver [EMAIL PROTECTED]:
Nice. If I were to work on the patches along those lines, is there a
starting point maybe? An initial set of uncommitted patches? API
suggestions?
OK, I'll have stab then. Here is what I had in mind:
- all AP_INIT_TAKE1 become AP_INIT_TAKE2, all
On 03/08/2006 12:49 AM, William A. Rowe, Jr. wrote:
Ruediger Pluem wrote:
OTH I guess we still have to convince some people to switch from mod_jk
to mod_proxy_ajp. So I guess having a similar behaviour in mod_proxy_ajp
as in mod_jk will ease this. Default for mod_jk is: No flushing.
On 03/08/2006 12:40 AM, Ruediger Pluem wrote:
The question that remains open to me is what kind of implementation should be
used
if force-flush is set to true?
The poll approach in the current code or flushing after each packet?
If the poll approach is used we need to make
I believe mod_jk added an explicit flush option rather than reverting
the default to flushing -- as I believe we suddenly had to add this
after our application stopped behaving properly and traced this issue back.
--
Jess Holle
William A. Rowe, Jr. wrote:
Ruediger Pluem wrote:
OTH I guess
For those in control of both endpoints, it would be nice to have a patch
to enable an extension to AJP in Tomcat 5.5.x and Apache 2.2 -- rather
than having to wait until Tomcat 6...
Of course, ideally said Tomcat patch would allow one to toggle at
runtime whether the extended protocol was
How about something like this? I whipped this out very quickly
and just did some quick compile and config-test tests on it...
Comments before I commit sometime tomorrow:
Index: modules/proxy/mod_proxy_ajp.c
===
---
Justin Erenkrantz wrote:
On 3/7/06, Jim Jagielski [EMAIL PROTECTED] wrote:
I would suggest that the bandaid code no longer be
compile time but rather runtime, using a
force-flush=3Dtrue param to the AJP worker.
I'd prefer that we not defer this decision to the users - we should
either
On 03/08/2006 03:46 AM, Jim Jagielski wrote:
How about something like this? I whipped this out very quickly
and just did some quick compile and config-test tests on it...
Comments before I commit sometime tomorrow:
Basicly looks good to me. Thanks for doing so. Some comments inline.
-
45 matches
Mail list logo
