408 with v3.1 behind apache/mod_proxy

[Dirk Rothe]

After upgrading to 3.1 we often get (exactly) the following response
if running behind a apache/mod_proxy:

TTP/1.1 408 Request TimeoutContent-Length: 0
Content-Type: text/plain


After disabling Line 993-995 in wgiserver/__init__.py [1] the problem
does not occure anymore. Any ideas what could be the cause of this
behaviour?

thnx, dirk


[1] http://cherrypy.org/browser/tags/cherrypy-3.1.0/cherrypy/wsgiserver/__init__.py#L993

[Chris Miles]

On Aug 9, 8:14 pm, Dirk Rothe <thec...@gmail.com> wrote:
> After upgrading to 3.1 we often get (exactly) the following response
> if running behind a apache/mod_proxy:
>
> TTP/1.1 408 Request TimeoutContent-Length: 0
> Content-Type: text/plain
>
> After disabling Line 993-995 in wgiserver/__init__.py [1] the problem
> does not occure anymore. Any ideas what could be the cause of this
> behaviour?

I'm seeing exactly the same problem. Your fix appears to help. The
odd things was that even when I rolled back to 3.1.0rc1 I was having
the same problem, and it doesn't contain that bit of code.

I'm running my app behind Apache 2.2.4, using mod_proxy behind a HTTPS
front-end, running on Solaris 10, if any of that helps.

Cheers,
Chris Miles

[Shawn]

On 9 Aug, 05:14, Dirk Rothe <thec...@gmail.com> wrote:
> After upgrading to 3.1 we often get (exactly) the following response
> if running behind a apache/mod_proxy:
>
> TTP/1.1 408 Request TimeoutContent-Length: 0
> Content-Type: text/plain
>
> After disabling Line 993-995 in wgiserver/__init__.py [1] the problem
> does not occure anymore. Any ideas what could be the cause of this
> behaviour?

I've seen the same behaviour, but it seems like that change would be
the wrong one.

Nevertheless, I'd be interested in knowing why the timeouts occur so
frequently.

-Shawn

[Dirk Rothe]

On Aug 20, 12:11 am, Shawn <binarycrusa...@gmail.com> wrote:

> I've seen the same behaviour, but it seems like that change would be
> the wrong one.

yeah, disabling the 'timed out' handling is a very crude fix. But it
does help.

@Robert: What was the reason to add the code from 3.0 to 3.1 in the
first place?

--dirk

[Yann Ramin]

Its probably from mod_proxy doing very long term keep-alive
connections, which time out for some reason or another. I've hit this
issue too upgrading to 3.1.

[Sylvain Hellegouarch]

FYI, I see the time out error consistently with CP 3.1 and httplib2
without any intermediary.

- Sylvain

> [1]http://cherrypy.org/browser/tags/cherrypy-3.1.0/cherrypy/wsgiserver/_...

[Sylvain Hellegouarch]

FYI, it happens then: http://cherrypy.org/ticket/810

[fumanchu]

Can't remember now what triggered the thought. But we really *should*
return 408 there, and I think the implementation is sound. Can't this
be fixed by simply increasing server.socket_timeout?


Robert Brewer
fuma...@aminus.org

[Stefan J. Betz]

Am 2008-09-27 20:51:06 -0700, fumanchu schrieb:
> Can't remember now what triggered the thought. But we really *should*
> return 408 there, and I think the implementation is sound. Can't this
> be fixed by simply increasing server.socket_timeout?

For Apache + mod_proxy disabling HTTP 1.1 Keepalive in the vhost Config
works for me -> http://cherrypy.org/ticket/853

If a increased server.socket_timeout works -> I don't Know!

mfg Betz Stefan
--
Betz Stefan -- Webdesign & Computerservice
URL: http://www.stefan-betz.net
Mail: in...@stefan-betz.net

[Shawn]

That's not really a fix though, right?

I think the main point is that there are a significant increase in
these errors and it is uncertain at this point whether that is simply
because of the exposure of a deeper problem as you mentioned earlier,
or because of configuration.

I'll be trying out a socket_timeout of 300 instead of the 60 I'm using
now and post back here.

Cheers,
-Shawn