Ray Morris wrote:
Google Content-Disposition. This is techincally a
MAIL header, not an HTTP header, I think, but the
major browsers seem to pay some attention to it,
at least some times.
Ah, that's perfect. Firefox honors it on Save As...,
and Safari honors it on both Save As... and when
+---+
| Bugzilla Bug ID |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned
Just a quick update; I have windows running again after creating a NUL
(/dev/null) association for the parent processes' stdout handle. It solves
a regression introduced in r483967 on Windows.
I'm somewhat puzzled, on traditional unix, NO_PIPE values for stdin/out/err
would pass no fd at all,
On 8/20/07, William A. Rowe, Jr. [EMAIL PROTECTED] wrote:
Just a quick update; I have windows running again after creating a NUL
(/dev/null) association for the parent processes' stdout handle. It solves
a regression introduced in r483967 on Windows.
D00d!!
Status Update:
There are issues in the current shipping version of
APR 0.9 that must be resolved before we can reroll 2.0.x.
Furthermore, there are issues in APR 1.2 that should be
fixed (although not regression related) before we redo
2.2.x... Once APR is tagged and rolled, we will use
that to
Jim Jagielski wrote:
Status Update:
There are issues in the current shipping version of
APR 0.9 that must be resolved before we can reroll 2.0.x.
Furthermore, there are issues in APR 1.2 that should be
fixed (although not regression related) before we redo
2.2.x... Once APR is tagged and
On Aug 20, 2007, at 4:36 PM, William A. Rowe, Jr. wrote:
Jim Jagielski wrote:
Status Update:
There are issues in the current shipping version of
APR 0.9 that must be resolved before we can reroll 2.0.x.
Furthermore, there are issues in APR 1.2 that should be
fixed (although not regression
Jim Jagielski wrote:
Of course, releases can't be vetoed, but doing further research
indicates that Bill looks to be spot on with this issue...
The point is, this was released. Iteratively. I'm just not in a mood
to keep +1'ing releases while the code remains in this broken state.
It
On Mon, Aug 20, 2007 at 03:36:59PM -0500, William Rowe wrote:
The crux of the problem is that we create processes without a full host
of three fd's. Then we inflict them against sh. Linux/bash doesn't seem
to mind, but solaris sh, and I'm guessing aix and hpux stock /bin/sh are
not going to
William A. Rowe, Jr. wrote:
Jim Jagielski wrote:
Of course, releases can't be vetoed, but doing further research
indicates that Bill looks to be spot on with this issue...
The point is, this was released. Iteratively. I'm just not in a mood
to keep +1'ing releases while the code
Short: We need to call ap_close_listeners() earlier or more aggressively.
Question: Where/How?
Looking at the Event MPM in both trunk and 2.2.x, the listener_thread is
where we call ap_close_listeners(). This does not seem to be working
quickly enough, per PR 43081:
11 matches
Mail list logo
