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
