You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Kevin <li...@gnosysllc.com> on 2007/03/03 21:50:11 UTC
Status of Bug # 39243
Hi List-
This isn't a support question, so please don't ignore it.
It's a legitimate dev-type question on the status of an open bug that I
don't see answers to on bugzilla at:
http://issues.apache.org/bugzilla/show_bug.cgi?id=39243
Can anyone share any sort of status on this bug?
I'm running into this bug with 2.2.3 and plone (as indicated in my
comment on bugzilla), and it really puts a huge damper on what I can do
with plone.
Surely there are other people that are suffering consequences of this
bug, no? How are you working around it?
Are there any plans to resolve this any time soon? I'm guessing it's
still present in 2.2.4 since I don't see anything in the change log
about it.
Can anyone comment?
If it's not going to be resolved in apache soon, then I'm going to have
to find a completely different solution.
Thanks in advance.
-Kevin
Re: Status of Bug # 39243
Posted by Ruediger Pluem <rp...@apache.org>.
On 03/04/2007 12:28 AM, William A. Rowe, Jr. wrote:
> Nick Kew wrote:
>
>>On Sat, 03 Mar 2007 17:16:52 -0600
>>"William A. Rowe, Jr." <wr...@rowe-clan.net> wrote:
>>
>>
>>>I'm contemplating an HTTP/1.1-only solution, available only if the
>>>client is willing to present expect-header 100-continue, which would
>>>involve no buffering.
>>
>>In principle:
>>+1 if it doesn't break current functionality with HTTP/1.0
>>-1 otherwise.
>>
>>To the OP: why not apply the fix suggested in the bug comments?
>>Define the size you want to use.
>
>
> It wouldn't change existing behavior, if there's no expect-header, we
> cannot do a renegotiate because we have no way to confirm that the
> client isn't waiting for 100 continue.
>
> If the client presents 100 continue we could toggle this behavior to
> renegotiate immediately, prior to offering the 100 continue response.
I also thought along these lines, but it seems that IE / Firefox do not
send an Expect: 100-continue header with their POST requests or am I wrong?
In this case this would not help.
BTW: I think if the client sents an Expect: 100-continue header this already
works today, at least according to the comments in ssl_hook_Access of
ssl_engine_kernel.c and a first quick analysis of the code:
/* If a renegotiation is now required for this location, and the
* request includes a message body (and the client has not
* requested a "100 Continue" response), then the client will be
* streaming the request body over the wire already. In that
* case, it is not possible to stop and perform a new SSL
* handshake immediately; once the SSL library moves to the
* "accept" state, it will reject the SSL packets which the client
* is sending for the request body.
*
* To allow authentication to complete in this auth hook, the
* solution used here is to fill a (bounded) buffer with the
* request body, and then to reinject that request body later.
*/
Regards
Rüdiger
Re: Status of Bug # 39243
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Nick Kew wrote:
> On Sat, 03 Mar 2007 17:16:52 -0600
> "William A. Rowe, Jr." <wr...@rowe-clan.net> wrote:
>
>> I'm contemplating an HTTP/1.1-only solution, available only if the
>> client is willing to present expect-header 100-continue, which would
>> involve no buffering.
>
> In principle:
> +1 if it doesn't break current functionality with HTTP/1.0
> -1 otherwise.
>
> To the OP: why not apply the fix suggested in the bug comments?
> Define the size you want to use.
It wouldn't change existing behavior, if there's no expect-header, we
cannot do a renegotiate because we have no way to confirm that the
client isn't waiting for 100 continue.
If the client presents 100 continue we could toggle this behavior to
renegotiate immediately, prior to offering the 100 continue response.
Re: Status of Bug # 39243
Posted by Nick Kew <ni...@webthing.com>.
On Sat, 03 Mar 2007 17:16:52 -0600
"William A. Rowe, Jr." <wr...@rowe-clan.net> wrote:
> I'm contemplating an HTTP/1.1-only solution, available only if the
> client is willing to present expect-header 100-continue, which would
> involve no buffering.
In principle:
+1 if it doesn't break current functionality with HTTP/1.0
-1 otherwise.
To the OP: why not apply the fix suggested in the bug comments?
Define the size you want to use.
--
Nick Kew
Application Development with Apache - the Apache Modules Book
http://www.apachetutor.org/
Re: Status of Bug # 39243
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
I'm contemplating an HTTP/1.1-only solution, available only if the client
is willing to present expect-header 100-continue, which would involve
no buffering.
Bill
Ruediger Pluem wrote:
>
> On 03/03/2007 09:50 PM, Kevin wrote:
>> Hi List-
>>
>> This isn't a support question, so please don't ignore it.
>>
>> It's a legitimate dev-type question on the status of an open bug that I
>> don't see answers to on bugzilla at:
>>
>> http://issues.apache.org/bugzilla/show_bug.cgi?id=39243
>>
>> Can anyone share any sort of status on this bug?
>>
>> I'm running into this bug with 2.2.3 and plone (as indicated in my
>> comment on bugzilla), and it really puts a huge damper on what I can do
>> with plone.
>
>>>From your comments in bugzilla I am not really sure if you are working with client
> certificates (I see you talking about SSL in general only). And even if you are
> working with client certificates this only affects you in the case that you
> are using Directory or Location based client certificates which require a SSL renegotiation.
> Plus your POST request needs to be the first operation during your connection
> to this Location / Directory.
>
>> Surely there are other people that are suffering consequences of this
>> bug, no? How are you working around it?
>>
>> Are there any plans to resolve this any time soon? I'm guessing it's
>
> No, currently there are no plans to change this. Please have a look at
>
> http://issues.apache.org/bugzilla/show_bug.cgi?id=39243#c3
> http://issues.apache.org/bugzilla/show_bug.cgi?id=39243#c7
> http://issues.apache.org/bugzilla/show_bug.cgi?id=39243#c14
>
> for reasons.
>
> Regards
>
> Rüdiger
>
>
>
>
Re: Status of Bug # 39243
Posted by Kevin <li...@gnosysllc.com>.
Ruediger Pluem wrote:
>
> On 03/03/2007 09:50 PM, Kevin wrote:
>> Hi List-
>>
>> This isn't a support question, so please don't ignore it.
>>
>> It's a legitimate dev-type question on the status of an open bug that I
>> don't see answers to on bugzilla at:
>>
>> http://issues.apache.org/bugzilla/show_bug.cgi?id=39243
>>
>> Can anyone share any sort of status on this bug?
>>
>> I'm running into this bug with 2.2.3 and plone (as indicated in my
>> comment on bugzilla), and it really puts a huge damper on what I can do
>> with plone.
>
> From your comments in bugzilla I am not really sure if you are working with client
> certificates (I see you talking about SSL in general only).
Sorry, I should have added that. I'm not working with any client
certificates at all. The only certificate in the picture is the server
certificate. Now, there are some Rewrite rules going on, to get the
connection from real_ip_address:443 to localhost:8080 (where zope is
listening). And zope/plone allow for authentication to be done using
the contents of an LDAP Directory, and that is in the picture too. This
LDAP aspect does not seem to be a factor though, because two sites that
I operate both suffer from this bug, and one uses LDAP-authentication
and the other uses native plone-based authentication.
I've tried this with two different browsers: current versions of Mozilla
Firefox and Mozilla Camino in OSX so I'm quite sure that there is no
hidden client certificate negotiation going on between browser and server.
> And even if you are
> working with client certificates this only affects you in the case that you
> are using Directory or Location based client certificates which require a SSL renegotiation.
Well, I don't know how zope/plone implement this behavior, but uploading
content in a plone site is done by filling out a form and pressing the
"Save/Send" button in the plone site. What happens after I press that
button I'm not sure. I've posted this comment to the plone.users list
also, and have generated some interest there. Perhaps the plone and
apache folks should be talking to each other on this. What would be the
best way to facilitate that? Is list cross-posting discouraged?
> Plus your POST request needs to be the first operation during your connection
> to this Location / Directory.
My last comment above applies here too.
>
>> Surely there are other people that are suffering consequences of this
>> bug, no? How are you working around it?
>>
>> Are there any plans to resolve this any time soon? I'm guessing it's
>
> No, currently there are no plans to change this. Please have a look at
>
> http://issues.apache.org/bugzilla/show_bug.cgi?id=39243#c3
> http://issues.apache.org/bugzilla/show_bug.cgi?id=39243#c7
> http://issues.apache.org/bugzilla/show_bug.cgi?id=39243#c14
>
Thanks for your reply. I will elaborate my bugzilla post to include the
absence of client certificate involvement.
-Kevin
Re: Status of Bug # 39243 (solved my problem)
Posted by Kevin <li...@gnosysllc.com>.
After all the discussion, and rereading documentation and config files
and the bug report several times over, I noticed that my apache server
config file used the SSLVerifyClient Directive at level "optional" and
that the documentation states, "In practice only levels 'none' and
'require' are really interesting, because level 'optional' doesn't work
with all browsers". I was also using the SSLVerifyDepth Directive at a
depth number of 1.
By commenting out these two directives (the default level for the first
is none), I solved the problem.
When I remarked earlier that client certificates were not involved at
all, I mistakenly considered only what was going on with the client,
failing to consider client certificate directives on the server.
Apologies if I should have thought of that sooner, and thanks for all
the helpful replies.
Hope this helps some other folks.
-Kevin
Re: Status of Bug # 39243
Posted by Joe Orton <jo...@redhat.com>.
On Sun, Mar 04, 2007 at 01:13:08PM +0100, Ruediger Pluem wrote:
> On 03/04/2007 01:53 AM, Kevin wrote:
> > I guess redhat has applied some sort of patch. Does anyone know abou
>
> I don't think so. Joe?
For the record, no, we don't use anything different to the upstream code
here.
Also (non-relevance of this user's report notwithstanding) I think there
has been enough demand demonstrated that that this limit should be made
user-configurable.
joe
Re: Status of Bug # 39243
Posted by Ruediger Pluem <rp...@apache.org>.
On 03/04/2007 01:53 AM, Kevin wrote:
> When I upload files 128kb and smaller, it works as expected. When I
> attempt to upload files 129kb and larger, I get this:
>
> Error message in browser:
> Title: 413 Request Entity Too Large
> Page: Request Entity Too Large
> The requested resource
> /Members/admin/portal_factory/Image/image.2007-03-03.9545920618/atct_edit
> does not allow request data with POST requests, or the amount of data
> provided in the request exceeds the capacity limit.
>
> Error message in logs:
> [Sat Mar 03 19:26:35 2007] [error] [client xxx.yyy.zzz.ttt] request body
> exceeds maximum size for SSL buffer, referer:
> https://www.example.com/Members/admin/portal_factory/Image/image.2007-03-03.9545920618/edit
>
> [Sat Mar 03 19:26:35 2007] [error] [client xxx.yyy.zzz.ttt] could not
> buffer message body to allow SSL renegotiation to proceed, referer:
> https://www.example.com/Members/admin/portal_factory/Image/image.2007-03-03.9545920618/edit
Given the error messages above I think that you are affected somehow by #39243, but the reason
seems to be a little different in your case. #39243 talks about client certificates in a directory
context, but the underlying problem is the need for a SSL renegotiation, which is triggered in the
client certificate case, but also triggered by other situations. So please do the following
(please attach all this info to the report):
1. Set the log level to debug (Attention: very verbose in the SSL case).
2. Try to upload more than 128k.
2. Add your access log and error log(s) to the report.
3. Add the configuration of your SSL host.
4. If you have any directives starting with SSL outside of your SSL host
attach these configuration blocks too.
5. Don't forget .htaccess files that contain SSL directives.
>
> I've spoken with someone on the plone list who's using RHEL and
> apache/ssl/plone in the same manner that I am, and he reports not
> suffering from this problem. I'm not sure if he has any upper limit at
> all, or if the upper limit is simply larger than 128kb. I'm still
> talking with him.
Maybe he has a slightly different configuration (see my remarks above).
>
> I guess redhat has applied some sort of patch. Does anyone know abou
I don't think so. Joe?
Regards
Rüdiger
Re: Status of Bug # 39243
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Kevin wrote:
>
> Is it your take then, that this problem only manifests itself in a
> poorly designed web application? If so, I'll pass that along to the
> plone developers and maybe they need to modify some of their code.
That's not what that article, or a host of others, has to say about the
matter. The issue is that the original expectations...
Client
POST /something HTTP/1.1
Host: myserver.com
Expect: 100-continue
{Client Headers}
|
V
Server
XXX ERROR RESULT
100 CONTINUE
{Server Headers}
|
V
{Client request body}
|
V
Server
XXX OK OR ERROR RESULT
{Server Headers}
{Server Response Body}
has been violated by any number of clients and servers in interesting
ways, leading to additional workarounds that again violate more combos
of clients and servers. A vicious cycle.
> But if the failures I'm seeing have nothing to do with apache itself,
> then why is apache throwing the error? Realize that I'm not familiar
> with the code in question.
Apache passes on whatever request body and respond it's supposed to pass
on between the client and the application.
It will respond TOO LARGE if your application decides to respond with that.
It will respond TOO LARGE if you have configured LimitRequestBody and the
size of the POST exceeds your limit.
http://httpd.apache.org/docs/2.2/mod/core.html#limitrequestbody
Want to know how to get 'out of' that bug? Try configuring on an internal
only (firewalled) port to respond from your application without SSL at all.
Bill
Re: Status of Bug # 39243
Posted by Kevin <li...@gnosysllc.com>.
William A. Rowe, Jr. wrote:
> Kevin wrote:
>> Additionally, I've added the following to the bug report:
>>
>> Sorry. I should have added above that there are no client certificates
>> involved in these uploads. I'm not savvy enough about the internals of
>> either apache or plone to know, but I suppose that means it's possible
>> that what I'm seeing is not actually this bug, but the behavior of my
>> systems match the symptoms in every way except for the involvement of
>> client certificates
>
> Exactly; your report doesn't belong in 39243 at all if you don't use the
> client certificate functions.
>
Well, not knowing apache internals myself, it seems I must accept your
statement here. But doing so leaves a number of questions unanswered.
> I came across a number of documents (google might be useful to you here)
> that refer to IE's behavior
Google brought me to the apache bug report in the first place when I had
nothing to go on but a 413 error being thrown by my apache server.
>
> http://www.motobit.com/help/scptutl/pa81.htm
> "2. Read all the source data. Client browsers accepts only one response:
> 100 continue. Or, as IE - the browser ignores initial server response -
> sends the form data regardless of the response."
>
> Which might mean 1. we need to be able to disable this behavior relative
> to bug 39243 (100-continue-async or something), and 2. have some relevance
> on how your POST-accepting application is failing. But I suspect your
> failures have nothing to do with "Apache" itself.
Is it your take then, that this problem only manifests itself in a
poorly designed web application? If so, I'll pass that along to the
plone developers and maybe they need to modify some of their code.
But if the failures I'm seeing have nothing to do with apache itself,
then why is apache throwing the error? Realize that I'm not familiar
with the code in question.
Bottom line is:
a) I don't see this problem in plone sites that are configured
identically with regard to being fronted by apache, but that are not
secured with ssl;
b) that the error is being thrown by apache (apache logs an error in its
error logs), not by plone;
c) that it is an extreme limitation on any site where it is common
practice to upload large files, and it's quite common to want to secure
such sites with SSL.
If the cause of these problems is not bug 39243, then I can't help
thinking that I should open a new bug report for my situation.
Thank you for the comments.
-Kevin
Re: Status of Bug # 39243
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Kevin wrote:
>
> Additionally, I've added the following to the bug report:
>
> Sorry. I should have added above that there are no client certificates
> involved in these uploads. I'm not savvy enough about the internals of
> either apache or plone to know, but I suppose that means it's possible
> that what I'm seeing is not actually this bug, but the behavior of my
> systems match the symptoms in every way except for the involvement of
> client certificates
Exactly; your report doesn't belong in 39243 at all if you don't use the
client certificate functions.
I came across a number of documents (google might be useful to you here)
that refer to IE's behavior
http://www.motobit.com/help/scptutl/pa81.htm
"2. Read all the source data. Client browsers accepts only one response:
100 continue. Or, as IE - the browser ignores initial server response -
sends the form data regardless of the response."
Which might mean 1. we need to be able to disable this behavior relative
to bug 39243 (100-continue-async or something), and 2. have some relevance
on how your POST-accepting application is failing. But I suspect your
failures have nothing to do with "Apache" itself.
Bill
Re: Status of Bug # 39243
Posted by Kevin <li...@gnosysllc.com>.
Ruediger Pluem wrote:
> From your comments in bugzilla I am not really sure if you are working with client
> certificates (I see you talking about SSL in general only). And even if you are
> working with client certificates this only affects you in the case that you
> are using Directory or Location based client certificates which require a SSL renegotiation.
> Plus your POST request needs to be the first operation during your connection
> to this Location / Directory.
>
Sorry for having missed the point about client certificates.
Additionally, I've added the following to the bug report:
Sorry. I should have added above that there are no client certificates
involved in these uploads. I'm not savvy enough about the internals of
either apache or plone to know, but I suppose that means it's possible
that what I'm seeing is not actually this bug, but the behavior of my
systems match the symptoms in every way except for the involvement of
client certificates, so to me that means that if they are not the same,
then they are at least, very probably strongly associated with each other.
When I upload files 128kb and smaller, it works as expected. When I
attempt to upload files 129kb and larger, I get this:
Error message in browser:
Title: 413 Request Entity Too Large
Page: Request Entity Too Large
The requested resource
/Members/admin/portal_factory/Image/image.2007-03-03.9545920618/atct_edit
does not allow request data with POST requests, or the amount of data
provided in the request exceeds the capacity limit.
Error message in logs:
[Sat Mar 03 19:26:35 2007] [error] [client xxx.yyy.zzz.ttt] request body
exceeds maximum size for SSL buffer, referer:
https://www.example.com/Members/admin/portal_factory/Image/image.2007-03-03.9545920618/edit
[Sat Mar 03 19:26:35 2007] [error] [client xxx.yyy.zzz.ttt] could not
buffer message body to allow SSL renegotiation to proceed, referer:
https://www.example.com/Members/admin/portal_factory/Image/image.2007-03-03.9545920618/edit
I've spoken with someone on the plone list who's using RHEL and
apache/ssl/plone in the same manner that I am, and he reports not
suffering from this problem. I'm not sure if he has any upper limit at
all, or if the upper limit is simply larger than 128kb. I'm still
talking with him.
I guess redhat has applied some sort of patch. Does anyone know about
that? Is it the same one mentioned in this bug report? I'd like to
have the limit (if it must exist) be up in the 40-50 MB range myself.
If there's another patch, perhaps someone could refer me to it?
Thanks.
-Kevin
Re: Status of Bug # 39243
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Kevin wrote:
>
> Do I understand correctly from this comment that if a user connects to
> the site using a client certificate, and if the SSLClientVerify step
> happens before the attempted post operation, that the problem won't
> occur? If so, then I should be home free, because with plone, one must
> GET a page first, before POSTing any data using the form in question.
PROVIDED keep alives are true, or possibly if the session ID is cached
and reused (I'm fuzzy on the second possibility - it may still fail since
the cached session may or may not recognize that the client credentials
were negotiated.)
Re: Status of Bug # 39243
Posted by Kevin <li...@gnosysllc.com>.
Ruediger Pluem wrote:
>
> No, currently there are no plans to change this. Please have a look at
>
> http://issues.apache.org/bugzilla/show_bug.cgi?id=39243#c14
>
Do I understand correctly from this comment that if a user connects to
the site using a client certificate, and if the SSLClientVerify step
happens before the attempted post operation, that the problem won't
occur? If so, then I should be home free, because with plone, one must
GET a page first, before POSTing any data using the form in question.
With regard to this comment:
http://issues.apache.org/bugzilla/show_bug.cgi?id=39243#c12
Would someone be so kind as to interpret that code snippet for me? Is
that a patch that I could apply to 2.2.4 apache sources and set a config
parameter SSL_MAX_IO_BUFFER in some appropriate context in my config
files, and thus eliminate the problem for myself (if exposing myself to
the DoS vulnerability---I have a very small and trustworthy user base)?
Is this the patch that redhat is using? Or is there another patch to
remove this limitation?
Many thanks for your detailed replies.
-Kevin
Re: Status of Bug # 39243
Posted by Ruediger Pluem <rp...@apache.org>.
On 03/03/2007 09:50 PM, Kevin wrote:
> Hi List-
>
> This isn't a support question, so please don't ignore it.
>
> It's a legitimate dev-type question on the status of an open bug that I
> don't see answers to on bugzilla at:
>
> http://issues.apache.org/bugzilla/show_bug.cgi?id=39243
>
> Can anyone share any sort of status on this bug?
>
> I'm running into this bug with 2.2.3 and plone (as indicated in my
> comment on bugzilla), and it really puts a huge damper on what I can do
> with plone.
>From your comments in bugzilla I am not really sure if you are working with client
certificates (I see you talking about SSL in general only). And even if you are
working with client certificates this only affects you in the case that you
are using Directory or Location based client certificates which require a SSL renegotiation.
Plus your POST request needs to be the first operation during your connection
to this Location / Directory.
>
> Surely there are other people that are suffering consequences of this
> bug, no? How are you working around it?
>
> Are there any plans to resolve this any time soon? I'm guessing it's
No, currently there are no plans to change this. Please have a look at
http://issues.apache.org/bugzilla/show_bug.cgi?id=39243#c3
http://issues.apache.org/bugzilla/show_bug.cgi?id=39243#c7
http://issues.apache.org/bugzilla/show_bug.cgi?id=39243#c14
for reasons.
Regards
Rüdiger