You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@httpd.apache.org by Travis Jensen <tr...@oracle.com> on 2013/08/05 20:20:51 UTC

[users@httpd] 408 timeout with mod_rewrite redirect to another server

I've got a fairly simple rewrite rule that bounces our Python pycurl 
client from the main server to a new server that actually dishes out the 
file:

|RewriteRule ^/update-repository/windsington(/.*)?$ http://newsvr.example.com/update-repository/windsington-real$1 [R=307,L]
|

Our client downloads a set of files and is connecting to both servers 
through our network proxy.

The first file downloads just fine, but the second invariably gives a 
"408 Request Time-out". If I run the process again, the file that 
previously timed out now downloads fine (since it is the first file to 
be downloaded) and the next file gives me a 408. If I keep doing this, 
I'll eventually get all of the files downloaded.

I've tried reproducing using wget and using a little sample python 
program using pycurl, but I can't reproduce it.

What I'm hoping for here is some advice on how to debug this thing 
inside of Apache (yes, the 408 definitely comes from the redirecting 
server and not the proxy or the server redirected to; the 408 is in the 
access logs). Obviously, something in the client/proxy is being sent 
that is tripping Apache, but I don't know Apache well enough to know how 
to debug this kind of thing. Alternatively, could libcurl be getting 
tripped up on something?

Another interesting thing is that, in the access log, the successful 
download has a proper user agent string, but in the failed download, it 
does not.

Version information:

  * Apache: 2.2.16 running on Debian Squeeze.
  * Pycurl: libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5
  * Python: 2.4 on CentOS 5.7

Thanks.

tj

Re: [users@httpd] 408 timeout with mod_rewrite redirect to another server

Posted by Igor Cicimov <ic...@gmail.com>.
On 07/08/2013 5:23 AM, "Travis Jensen" <tr...@oracle.com> wrote:
>
> On 8/5/13 3:57 PM, Igor Cicimov wrote:
>>
>>
>> On 06/08/2013 4:21 AM, "Travis Jensen" <tr...@oracle.com> wrote:
>> >
>> > I've got a fairly simple rewrite rule that bounces our Python pycurl
client from the main server to a new server that actually dishes out the
file:
>> >
>> > RewriteRule ^/update-repository/windsington(/.*)?$
http://newsvr.example.com/update-repository/windsington-real$1 [R=307,L]
>> >
>> > Our client downloads a set of files and is connecting to both servers
through our network proxy.
>> >
>> > The first file downloads just fine, but the second invariably gives a
"408 Request Time-out". If I run the process again, the file that
previously timed out now downloads fine (since it is the first file to be
downloaded) and the next file gives me a 408. If I keep doing this, I'll
eventually get all of the files downloaded.
>> >
>> > I've tried reproducing using wget and using a little sample python
program using pycurl, but I can't reproduce it.
>> >
>> > What I'm hoping for here is some advice on how to debug this thing
inside of Apache (yes, the 408 definitely comes from the redirecting server
and not the proxy or the server redirected to; the 408 is in the access
logs). Obviously, something in the client/proxy is being sent that is
tripping Apache, but I don't know Apache well enough to know how to debug
this kind of thing. Alternatively, could libcurl be getting tripped up on
something?
>> >
>> > Another interesting thing is that, in the access log, the successful
download has a proper user agent string, but in the failed download, it
does not.
>> >
>> > Version information:
>> >
>> > Apache: 2.2.16 running on Debian Squeeze.
>> > Pycurl: libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5
>> > Python: 2.4 on CentOS 5.7
>> > Thanks.
>> >
>> > tj
>> Enable the rewrite log and check for errors. Read the mod_rewrite docs
if you need help.
>
>
> I enabled logging (tried at level 1, 2, and 3).  The first request (the
working one) shows up fine; the second request, the one that is failing,
never gets logged. It looks like, for whatever reason, the request is not
getting passed to mod_rewrite.
>
> Where can I look next?
>
> Thanks.
>
> tj
Do you have
LogLevel debug
set as well? Then check the error log.

Re: [users@httpd] 408 timeout with mod_rewrite redirect to another server

Posted by Travis Jensen <tr...@oracle.com>.
On 8/5/13 3:57 PM, Igor Cicimov wrote:
>
>
> On 06/08/2013 4:21 AM, "Travis Jensen" <travis.jensen@oracle.com 
> <ma...@oracle.com>> wrote:
> >
> > I've got a fairly simple rewrite rule that bounces our Python pycurl 
> client from the main server to a new server that actually dishes out 
> the file:
> >
> > RewriteRule ^/update-repository/windsington(/.*)?$ 
> http://newsvr.example.com/update-repository/windsington-real$1 [R=307,L]
> >
> > Our client downloads a set of files and is connecting to both 
> servers through our network proxy.
> >
> > The first file downloads just fine, but the second invariably gives 
> a "408 Request Time-out". If I run the process again, the file that 
> previously timed out now downloads fine (since it is the first file to 
> be downloaded) and the next file gives me a 408. If I keep doing this, 
> I'll eventually get all of the files downloaded.
> >
> > I've tried reproducing using wget and using a little sample python 
> program using pycurl, but I can't reproduce it.
> >
> > What I'm hoping for here is some advice on how to debug this thing 
> inside of Apache (yes, the 408 definitely comes from the redirecting 
> server and not the proxy or the server redirected to; the 408 is in 
> the access logs). Obviously, something in the client/proxy is being 
> sent that is tripping Apache, but I don't know Apache well enough to 
> know how to debug this kind of thing. Alternatively, could libcurl be 
> getting tripped up on something?
> >
> > Another interesting thing is that, in the access log, the successful 
> download has a proper user agent string, but in the failed download, 
> it does not.
> >
> > Version information:
> >
> > Apache: 2.2.16 running on Debian Squeeze.
> > Pycurl: libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5
> > Python: 2.4 on CentOS 5.7
> > Thanks.
> >
> > tj
> Enable the rewrite log and check for errors. Read the mod_rewrite docs 
> if you need help.
>

I enabled logging (tried at level 1, 2, and 3).  The first request (the 
working one) shows up fine; the second request, the one that is failing, 
never gets logged. It looks like, for whatever reason, the request is 
not getting passed to mod_rewrite.

Where can I look next?

Thanks.

tj

Re: [users@httpd] 408 timeout with mod_rewrite redirect to another server

Posted by Igor Cicimov <ic...@gmail.com>.
On 06/08/2013 4:21 AM, "Travis Jensen" <tr...@oracle.com> wrote:
>
> I've got a fairly simple rewrite rule that bounces our Python pycurl
client from the main server to a new server that actually dishes out the
file:
>
> RewriteRule ^/update-repository/windsington(/.*)?$
http://newsvr.example.com/update-repository/windsington-real$1 [R=307,L]
>
> Our client downloads a set of files and is connecting to both servers
through our network proxy.
>
> The first file downloads just fine, but the second invariably gives a
"408 Request Time-out". If I run the process again, the file that
previously timed out now downloads fine (since it is the first file to be
downloaded) and the next file gives me a 408. If I keep doing this, I'll
eventually get all of the files downloaded.
>
> I've tried reproducing using wget and using a little sample python
program using pycurl, but I can't reproduce it.
>
> What I'm hoping for here is some advice on how to debug this thing inside
of Apache (yes, the 408 definitely comes from the redirecting server and
not the proxy or the server redirected to; the 408 is in the access logs).
Obviously, something in the client/proxy is being sent that is tripping
Apache, but I don't know Apache well enough to know how to debug this kind
of thing. Alternatively, could libcurl be getting tripped up on something?
>
> Another interesting thing is that, in the access log, the successful
download has a proper user agent string, but in the failed download, it
does not.
>
> Version information:
>
> Apache: 2.2.16 running on Debian Squeeze.
> Pycurl: libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5
> Python: 2.4 on CentOS 5.7
> Thanks.
>
> tj
Enable the rewrite log and check for errors. Read the mod_rewrite docs if
you need help.