Hi!  For some reason I can't get wget or lynx to work with pound.  They
both return empty documents.  (Mozilla and IE work fine though.)  When I
connect to the IP that apache is listening to, it works.  I wrote a
quick perl script using Net::Telnet to dump the raw output, and
connected to both the pound IP and apache's IP, and the output was
identical (except for the Date: header obviously).

If anyone wants to try it for themselves, the url in question is
http://www.telana.com/.  Pound is listening on 66.109.156.44:80, and
apache is listening on 66.109.156.34:80 (same machine though).

Anyone else experiencing this behavior?

Sean

> Hi!  For some reason I can't get wget or lynx to work with pound.  They
> both return empty documents.  (Mozilla and IE work fine though.)  When I
> connect to the IP that apache is listening to, it works.  I wrote a
> quick perl script using Net::Telnet to dump the raw output, and
> connected to both the pound IP and apache's IP, and the output was
> identical (except for the Date: header obviously).
>
> If anyone wants to try it for themselves, the url in question is
> http://www.telana.com/.  Pound is listening on 66.109.156.44:80, and
> apache is listening on 66.109.156.34:80 (same machine though).

Hm, I don't really understand what you did and how? On
http://www.telana.com/ I get nothing or a 500 error while on both
66.109.156.34:80 and 66.109.156.44:80 I get a 404 error. Please put a
index.html in place, check your pound config and then try again. If you
want somebody to help you then at least provide your pound config here and
tell us something about your OS.

Simon

>
> Anyone else experiencing this behavior?
>
> Sean
>
>
>

> > Hi!  For some reason I can't get wget or lynx to work with pound.  They
> > both return empty documents.  (Mozilla and IE work fine though.)  When I
> > connect to the IP that apache is listening to, it works.  I wrote a
> > quick perl script using Net::Telnet to dump the raw output, and
> > connected to both the pound IP and apache's IP, and the output was
> > identical (except for the Date: header obviously).
>
> Hm, I don't really understand what you did and how? On
> http://www.telana.com/ I get nothing or a 500 error while on both
> 66.109.156.34:80 and 66.109.156.44:80 I get a 404 error. Please put a
> index.html in place, check your pound config and then try again. If you
> want somebody to help you then at least provide your pound config here and
> tell us something about your OS.

Okay; I didn't have apache configured to handle the raw IP access
without a Host: header, so that's fixed now.  As for a 500 error going
to the url (which hits pound), that's news to me - can't reproduce it
either.  Note that there's not much to speak of at that url right now -
just says "coming soon" :)

OS: Linux 2.6.0-test9-bk22 on an AMD64
Apache 2.0.48 (with an experimental perchild replacement called
metuxmpm)
Pound-current (downloaded about a week ago)

Everything is compiled for x86_64.

Here's my pound.conf:

User nobody
Group nobody
#RootJail /var/lib/pound
ListenHTTP 66.109.156.44,80
ListenHTTPS 66.109.156.44,443 /etc/pound/www.telana.com.pem
ExtendedHTTP 1
HTTPSHeaders 0 ""
LogLevel 2

# Catch-all server(s)
UrlGroup ".*"
BackEnd 66.109.156.34,80,1
EndGroup


I have RootJail commented out because it seems to slow down pound
considerably, at least when there are any graphics on the page.  I've
also tried setting various other configuration options (NoHTTP11,
turning off ExtendedHTTP, etc) but it doesn't change the behavior of
wget or lynx.

Here's the output of wget.  I set up http://www2.telana.com/ to go
straight to the apache interface, while http://www.telana.com/ goes to
pound:

$ wget http://www.telana.com/
--13:19:09--  http://www.telana.com/
           => `index.html'
Resolving www.telana.com... done.
Connecting to www.telana.com[66.109.156.44]:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
                                                                               

    [ <=>                                 ] 0             --.--K/s
                                                                               

13:19:09 (0.00 B/s) - `index.html' saved [0]

$ ls -l index.html
-rw-rw-r--    1 gabriel  gabriel         0 Jan  4 13:19 index.html

$ rm -f index.html

$ wget http://www2.telana.com/
--13:22:36--  http://www2.telana.com/
           => `index.html'
Resolving www2.telana.com... done.
Connecting to www2.telana.com[66.109.156.34]:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
 
    [ <=>                                 ] 100           97.66K/s
 
13:22:36 (97.66 KB/s) - `index.html' saved [100]

$ ls -l index.html
-rw-rw-r--    1 gabriel  gabriel       100 Jan  4 13:22 index.html

Okay, I've refined my problem.  It seems that pound is failing somehow
with HTTP/1.0 requests.  "GET / HTTP/1.1" works fine, but "GET /
HTTP/1.0" returns an empty document.  Any ideas on what I should
investigate next, with this information? :)

I'm using the latest Pound-current.tgz on an AMD64, linux kernel 2.6.1,
backend is apache 2.0.48.  btw, anyone else using pound on a 64-bit
arch?

Sean

On Wed, 2004-01-14 at 01:43, Seán Gabriel wrote:
> Okay, I've refined my problem.  It seems that pound is failing somehow
> with HTTP/1.0 requests.  "GET / HTTP/1.1" works fine, but "GET /
> HTTP/1.0" returns an empty document.  Any ideas on what I should
> investigate next, with this information? :)
> 
> I'm using the latest Pound-current.tgz on an AMD64, linux kernel 2.6.1,
> backend is apache 2.0.48.  btw, anyone else using pound on a 64-bit
> arch?
> 
> Sean
> 

Please make sure you really use the LATEST Pound-current (dated
12/12/2003), as it includes some patches that could have an effect on
this. If yes I would really appreciate if you could stick an instance of
tcpwatch between Pound and the back-end so we can see what goes wrong...
-- 
Robert Segall
Apsis GmbH
Postfach, Uetikon am See, CH-8707
Tel: +41-1-920 4904

On Wed, 2004-01-14 at 04:00, Robert Segall wrote:
> Please make sure you really use the LATEST Pound-current (dated
> 12/12/2003), as it includes some patches that could have an effect on.

Yeah, it's definately the latest one (I re-downloaded just in case)

> If yes I would really appreciate if you could stick an instance of
> tcpwatch between Pound and the back-end so we can see what goes
> wrong...

Okay, I haven't used tcpwatch before, but it seems pretty cool - here's
how I set it up:

66.109.156.44:80 (pound) ->
  66.109.156.34:8080 (tcpwatch) ->
  66.109.156.34:80 (apache)

(this is all on one machine, 66.109.156.34 is the primary IP on eth0
while 66.109.156.44 is an eth0 alias)

Here's the output of tcpwatch during an HTTP/1.1 request:

-------------------------------------------------------------

[00:00.000 - client 66.109.156.34:34603 forwarded to 66.109.156.34:80]
==>GET / HTTP/1.1
==>Host: www.telana.com:80
==>X-Forwarded-For: 64.25.140.29
==>
[00:00.001 - server connected]
<==HTTP/1.1 200 OK
<==Date: Wed, 14 Jan 2004 23:04:36 GMT
<==Server: Apache/2.0.48 (Red Hat Linux) PHP/5.0.0b3 DAV/2
<==X-Powered-By: PHP/5.0.0b3
<==Connection: close
<==Transfer-Encoding: chunked
<==Content-Type: text/html; charset=ISO-8859-1
<==
<==64
<==<html>
<==<head>
<== <title>Telana.com</title>
<==</head>
<==
<==<body bgcolor="white">
<==Coming Soon
<==</body>
<==</html>
<==0
<==
[00:00.021 - server closed]

-------------------------------------------------------------

and here's an HTTP/1.0 request:

-------------------------------------------------------------

[00:00.000 - client 66.109.156.34:34601 forwarded to 66.109.156.34:80]
[00:00.000 - server connected]
==>GET / HTTP/1.0
==>Host: www.telana.com:80
==>X-Forwarded-For: 64.25.140.29
==>
<==HTTP/1.1 200 OK
<==Date: Wed, 14 Jan 2004 23:03:14 GMT
<==Server: Apache/2.0.48 (Red Hat Linux) PHP/5.0.0b3 DAV/2
<==X-Powered-By: PHP/5.0.0b3
<==Connection: close
<==Content-Type: text/html; charset=ISO-8859-1
<==
<==<html>
<==<head>
<== <title>Telana.com</title>
<==</head>
<==
<==<body bgcolor="white">
<==Coming Soon
<==</body>
<==</html>
[00:00.024 - server closed]

-------------------------------------------------------------

I don't see any smoking guns here... the reply to the HTTP/1.0 request
doesn't use chunked encoding, which is probably a 1.1 thing anyway.  The
client receives only the headers, and no body, with an HTTP/1.0
request.  From this it looks like the body is at least getting to Pound.

Sean

On Thu, 2004-01-15 at 00:35, Seán Gabriel wrote:
> On Wed, 2004-01-14 at 04:00, Robert Segall wrote:
> > Please make sure you really use the LATEST Pound-current (dated
> > 12/12/2003), as it includes some patches that could have an effect on.
> 
> Yeah, it's definately the latest one (I re-downloaded just in case)
> 
> > If yes I would really appreciate if you could stick an instance of
> > tcpwatch between Pound and the back-end so we can see what goes
> > wrong...
> 
> Okay, I haven't used tcpwatch before, but it seems pretty cool - here's
> how I set it up:
> 
> 66.109.156.44:80 (pound) ->
>   66.109.156.34:8080 (tcpwatch) ->
>   66.109.156.34:80 (apache)
> 
> (this is all on one machine, 66.109.156.34 is the primary IP on eth0
> while 66.109.156.44 is an eth0 alias)

So far so good.

> Here's the output of tcpwatch during an HTTP/1.1 request:
> 
> -------------------------------------------------------------
> 
> [00:00.000 - client 66.109.156.34:34603 forwarded to 66.109.156.34:80]
> ==>GET / HTTP/1.1
> ==>Host: www.telana.com:80
> ==>X-Forwarded-For: 64.25.140.29
> ==>
> [00:00.001 - server connected]
> <==HTTP/1.1 200 OK
> <==Date: Wed, 14 Jan 2004 23:04:36 GMT
> <==Server: Apache/2.0.48 (Red Hat Linux) PHP/5.0.0b3 DAV/2
> <==X-Powered-By: PHP/5.0.0b3
> <==Connection: close
> <==Transfer-Encoding: chunked
> <==Content-Type: text/html; charset=ISO-8859-1
> <==
> <==64
> <==<html>
> <==<head>
> <== <title>Telana.com</title>
> <==</head>
> <==
> <==<body bgcolor="white">
> <==Coming Soon
> <==</body>
> <==</html>
> <==0
> <==
> [00:00.021 - server closed]
> 
> -------------------------------------------------------------
> 
> and here's an HTTP/1.0 request:
> 
> -------------------------------------------------------------
> 
> [00:00.000 - client 66.109.156.34:34601 forwarded to 66.109.156.34:80]
> [00:00.000 - server connected]
> ==>GET / HTTP/1.0
> ==>Host: www.telana.com:80
> ==>X-Forwarded-For: 64.25.140.29
> ==>
> <==HTTP/1.1 200 OK
> <==Date: Wed, 14 Jan 2004 23:03:14 GMT
> <==Server: Apache/2.0.48 (Red Hat Linux) PHP/5.0.0b3 DAV/2
> <==X-Powered-By: PHP/5.0.0b3
> <==Connection: close
> <==Content-Type: text/html; charset=ISO-8859-1
> <==
> <==<html>
> <==<head>
> <== <title>Telana.com</title>
> <==</head>
> <==
> <==<body bgcolor="white">
> <==Coming Soon
> <==</body>
> <==</html>
> [00:00.024 - server closed]
> 
> -------------------------------------------------------------
> 
> I don't see any smoking guns here... the reply to the HTTP/1.0 request
> doesn't use chunked encoding, which is probably a 1.1 thing anyway.  The
> client receives only the headers, and no body, with an HTTP/1.0
> request.  From this it looks like the body is at least getting to Pound.
> 
> Sean
> 

There is a smoking gun - Apache replies to a 1.1 request with a chunked
transfer, but to a 1.0 with a transfer without a Content-length (this is
essentially 0.9), while still claiming to be 1.1! Bad Apache!

I just uploaded a patched Pound-current version that should fix the
problem - give it a try and let us know. If it still gives you problems
try setting Server to higher values (30 or more) just to be sure...
-- 
Robert Segall
Apsis GmbH
Postfach, Uetikon am See, CH-8707
Tel: +41-1-920 4904

On Fri, 2004-01-16 at 02:40, Robert Segall wrote:
> There is a smoking gun - Apache replies to a 1.1 request with a chunked
> transfer, but to a 1.0 with a transfer without a Content-length (this is
> essentially 0.9), while still claiming to be 1.1! Bad Apache!

Ah, I bet it's a problem in metuxmpm (a perchild replacement, still
under development).  I'll see about fixing that, or at least alert the
developers.

> I just uploaded a patched Pound-current version that should fix the
> problem - give it a try and let us know. If it still gives you problems
> try setting Server to higher values (30 or more) just to be sure...

Works great!  Thanks for your help and for such an excellent piece of
software.

Sean