It may be a bit of a hack, but it seems reasonable to me. The best
part is that it works.
+1
Brad
[EMAIL PROTECTED] Wednesday, December 08, 2004 2:33:48 AM
On Tue, Dec 07, 2004 at 05:14:40PM -0700, Brad Nicholes wrote:
OK, now that you have enabled upgrades for anything other than
--On Wednesday, December 8, 2004 9:33 AM + Joe Orton [EMAIL PROTECTED]
wrote:
On Tue, Dec 07, 2004 at 05:14:40PM -0700, Brad Nicholes wrote:
OK, now that you have enabled upgrades for anything other than
OPTIONS, I see the problem. Even though there is a content-length
included in the
On Wed, Dec 08, 2004 at 08:22:49AM -0800, Justin Erenkrantz wrote:
--On Wednesday, December 8, 2004 9:33 AM + Joe Orton
[EMAIL PROTECTED] wrote:
On Tue, Dec 07, 2004 at 05:14:40PM -0700, Brad Nicholes wrote:
OK, now that you have enabled upgrades for anything other than
OPTIONS, I
--On Wednesday, December 8, 2004 8:53 PM + Joe Orton [EMAIL PROTECTED]
wrote:
I can't convince myself it would solve the general case, though: if both
r- and c-output_filters to happen point to the *same* filter,
modifying the filter chain without knowledge of r- (which is the
problem) will
It appears that the patch for bug 18757 which disallows a
content-length header for all requests with a content-length of 0 is too
broad.
Index: D:/Projects/2.x/httpd-trunk/server/protocol.c
===
---
On Tue, Dec 07, 2004 at 10:14:28AM -0700, Brad Nicholes wrote:
It appears that the patch for bug 18757 which disallows a
content-length header for all requests with a content-length of 0 is too
broad.
...
The bug simply says that the content-length should be removed just for
HEAD
On Tue, Dec 07, 2004 at 11:01:13AM -0700, Brad Nicholes wrote:
I tested the TLS upgrade stuff last week and it failed because the
zero-length chunk to terminate the OPTIONS response was not sent
through
the mod_ssl output filter; is that the same problem you see?
I don't think so. I can
So what are you suggesting that the appropriate fix should be? Even
though the protocol.c patch was bogus, it sounds like might have exposed
something else. In fact I am still not seeing where the problem is.
The protocol.c patch was just allowing a bad response to happen that
should never
On Tue, Dec 07, 2004 at 03:00:52PM -0700, Brad Nicholes wrote:
So what are you suggesting that the appropriate fix should be? Even
though the protocol.c patch was bogus, it sounds like might have exposed
something else. In fact I am still not seeing where the problem is.
Try doing an
OK, now that you have enabled upgrades for anything other than
OPTIONS, I see the problem. Even though there is a content-length
included in the header, you are saying that the header is being sent
encrypted but the content is not, correct? And the reason for this is
because there is more
10 matches
Mail list logo
