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
===
--- D:/Projects/2.x/httpd-trunk/ser
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 r
>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 make everything work again by simply allowing
the "Content-Length: 0"
This patch also looks bogus given the fact that the content-length
header for a r->header_only request is already being handled in
ap_http_header_filter(). Removing all Content-Length: 0 headers in the
ap_content_length_filter() seems like overkill.
Brad
>>> [EMAIL PROTECTED] Tuesday, Decembe
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.
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 ha
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 u
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 than
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 header, you are saying that the header is being sent
> encrypted but the content
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 tha
--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 h
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
> >>
--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) w
13 matches
Mail list logo
