1

I am attempting to simulate my site's production environment as closely as I can on my local machine. This is a rails site that uses Apache w/ mod_proxy to forward requests to a mongrel cluster. On my Mac OSX Leopard machine, I have the default install of apache running and have configured a vhost to use mod_proxy to to forward requests to a local running mongrel instance on port 3000. 

<Proxy balancer://mongrel_cluster-development> BalancerMember http://127.0.0.1:3000 </Proxy>

For the most part, this is working fine. I can browse my development site using the ServerName of the vhost I configured and can confirm that requests are being properly forwarded to the mongrel instance. However, there is a page on the site that has a multipart form that is used to upload an image to the server. When I post this form, there is a delay of about 5 minutes and the browser ultimately returns a

Bad Request Your browser sent a request that this server could not understand.

In the error log for my vhost:

[Tue Sep 22 09:47:57 2009] [error] (70007)The timeout specified has expired: proxy: prefetch request body failed to 127.0.0.1:3000 (127.0.0.1) from ::1 ()

This same form works fine if I browse directly to the mongrel instance (http://127.0.0.1:3000). Anybody have any idea what the problem might be and how to fix it? If there is any important information that I neglected to include, post a comment, and I can add to this question.

Note: Upon further investigation, this appears to be a problem specific to Safari. The form works fine in Firefox.

Improve this question
1
  • Do you have ProxyPass and ProxypassReverse lines? Those might be what you're looking for. Commented Aug 20, 2012 at 1:41

1 Answer 1

Reset to default
1

I think this problem cause by the limit of a cookie-header length.

The cookie-header's limitation of 'RFC 2109' is below:

  • at least 300 cookies
  • at least 4096 bytes per cookie
  • at least 20 cookies per unique host or domain name

When Safari send a large cookie header in sometime, Apache could not parse it. You may have to check the session header by using tcpmon (or like that).

Improve this answer

You must log in to answer this question.