Dear list,

I'm trying to connect pound to the simple HTTP server
from the Python library, both running on the same machine.

Environment:
FreeBSD 4.9
OpenSSL 0.9.7d built with threading support
Pound 1.7
Python 2.3.3

There's been no problem compiling and running Pound,
and it even works fine as a front-end for some external
HTTP server (IIS). I didn't give it a stress test,
but it returned some pages. I had to create a sample CA
and key/certificate pair, then install CA certificate to
all the browsers I have but this went easy.

Now, I run simple Python web server bundled with Python library:

# python /usr/local/lib/python2.3/BaseHTTPServer.py
Serving HTTP on 0.0.0.0 port 8000 ...

Then, I run Pound using the following pound.cfg file:
------------------
ListenHTTPS 192.168.126.129,443 /ca/servers/server_cert.pem

UrlGroup ".*"
BackEnd 127.0.0.1,8000,1
EndGroup
------------------

I can connect to http://192.168.126.129:8000/ using any outside
browser and it behaves precisely as expected (no HTTP GET handler):
----------------------------------------
Error response

Error code 501.

Message: Unsupported method.

Error code explanation: 501 = Server does not support this operation.
----------------------------------------

But when I connect to https://192.168.126.129/, Pound sees the
request:

and even passes it to the Python server (Python reports):

----------------------------------------
localhost.my.domain - - [24/May/2004 02:14:11] code 501, message Unsupported
method
localhost.my.domain - - [24/May/2004 02:14:11] "GET / HTTP/1.1" 501 -
----------------------------------------

but when Python writes the response back, bad thing happens
(/var/log/messages):

----------------------------------------
May 24 02:13:41 foo pound: headers: bad starting read
May 24 02:13:41 foo pound: response error read from 127.0.0.1:8000: Resource
temporarily unavailable
----------------------------------------

And the Python request handler crashes too:

----------------------------------------
Exception happened during processing of request from ('127.0.0.1', 12290)
Traceback (most recent call last):
  File "/usr/local/lib/python2.3/SocketServer.py", line 222, in handle_request
    self.process_request(request, client_address)
  File "/usr/local/lib/python2.3/SocketServer.py", line 241, in process_request
    self.finish_request(request, client_address)
  File "/usr/local/lib/python2.3/SocketServer.py", line 254, in finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "/usr/local/lib/python2.3/SocketServer.py", line 521, in __init__
    self.handle()
  File "/usr/local/lib/python2.3/BaseHTTPServer.py", line 324, in handle
    self.handle_one_request()
  File "/usr/local/lib/python2.3/BaseHTTPServer.py", line 315, in
handle_one_request
    self.send_error(501, "Unsupported method")
  File "/usr/local/lib/python2.3/BaseHTTPServer.py", line 351, in send_error
    self.send_response(code, message)
  File "/usr/local/lib/python2.3/BaseHTTPServer.py", line 377, in send_response
    self.send_header('Server', self.version_string())
  File "/usr/local/lib/python2.3/BaseHTTPServer.py", line 383, in send_header
    self.wfile.write("%s: %s\r\n" % (keyword, value))
  File "/usr/local/lib/python2.3/socket.py", line 254, in write
    self.flush()
  File "/usr/local/lib/python2.3/socket.py", line 241, in flush
    self._sock.sendall(buffer)
error: (32, 'Broken pipe')
----------------------------------------

I think the "bad starting read" message is a key, and it has to do
with some very simple misconfiguration.

Do you have any suggestions ?

Thank you.

Sincerely,
Dmitry Dvoinikov
http://www.targeted.org/

I think I found the bug that was causing weird behavior
when connecting to localhost (see my previous message).
It has to do with recent change to non-blocking connect -

in svc.c, line 712:
if(fcntl(sockfd, F_SETFL, flags | O_NONBLOCK) < 0) {
should be
if(fcntl(sockfd, F_SETFL, flags) < 0) {
because we really don't want the connected socket to remain
non-blocking.

I believe more testing is needed before declaring product like
that "production stable".

Sincerely,
Dmitry Dvoinikov
http://www.targeted.org/

--- Original message follows ---

> Dear list,

> I'm trying to connect pound to the simple HTTP server
> from the Python library, both running on the same machine.

> Environment:
> FreeBSD 4.9
> OpenSSL 0.9.7d built with threading support
> Pound 1.7
> Python 2.3.3

> There's been no problem compiling and running Pound,
> and it even works fine as a front-end for some external
> HTTP server (IIS). I didn't give it a stress test,
> but it returned some pages. I had to create a sample CA
> and key/certificate pair, then install CA certificate to
> all the browsers I have but this went easy.

> Now, I run simple Python web server bundled with Python library:

> # python /usr/local/lib/python2.3/BaseHTTPServer.py
> Serving HTTP on 0.0.0.0 port 8000 ...

> Then, I run Pound using the following pound.cfg file:
> ------------------
> ListenHTTPS 192.168.126.129,443 /ca/servers/server_cert.pem

> UrlGroup ".*"
> BackEnd 127.0.0.1,8000,1
> EndGroup
> ------------------

> I can connect to http://192.168.126.129:8000/ using any outside
> browser and it behaves precisely as expected (no HTTP GET handler):
> ----------------------------------------
> Error response

> Error code 501.

> Message: Unsupported method.

> Error code explanation: 501 = Server does not support this operation.
> ----------------------------------------

> But when I connect to https://192.168.126.129/, Pound sees the
> request:

> and even passes it to the Python server (Python reports):

> ----------------------------------------
> localhost.my.domain - - [24/May/2004 02:14:11] code 501, message Unsupported
method
> localhost.my.domain - - [24/May/2004 02:14:11] "GET / HTTP/1.1" 501 -
> ----------------------------------------

> but when Python writes the response back, bad thing happens
> (/var/log/messages):

> ----------------------------------------
> May 24 02:13:41 foo pound: headers: bad starting read
> May 24 02:13:41 foo pound: response error read from
> 127.0.0.1:8000: Resource temporarily unavailable
> ----------------------------------------

> And the Python request handler crashes too:

> ----------------------------------------
> Exception happened during processing of request from ('127.0.0.1', 12290)
> Traceback (most recent call last):
>   File "/usr/local/lib/python2.3/SocketServer.py", line 222, in
handle_request
>     self.process_request(request, client_address)
>   File "/usr/local/lib/python2.3/SocketServer.py", line 241, in
process_request
>     self.finish_request(request, client_address)
>   File "/usr/local/lib/python2.3/SocketServer.py", line 254, in
finish_request
>     self.RequestHandlerClass(request, client_address, self)
>   File "/usr/local/lib/python2.3/SocketServer.py", line 521, in __init__
>     self.handle()
>   File "/usr/local/lib/python2.3/BaseHTTPServer.py", line 324, in handle
>     self.handle_one_request()
>   File "/usr/local/lib/python2.3/BaseHTTPServer.py", line 315, in
handle_one_request
>     self.send_error(501, "Unsupported method")
>   File "/usr/local/lib/python2.3/BaseHTTPServer.py", line 351, in send_error
>     self.send_response(code, message)
>   File "/usr/local/lib/python2.3/BaseHTTPServer.py", line 377, in
send_response
>     self.send_header('Server', self.version_string())
>   File "/usr/local/lib/python2.3/BaseHTTPServer.py", line 383, in send_header
>     self.wfile.write("%s: %s\r\n" % (keyword, value))
>   File "/usr/local/lib/python2.3/socket.py", line 254, in write
>     self.flush()
>   File "/usr/local/lib/python2.3/socket.py", line 241, in flush
>     self._sock.sendall(buffer)
> error: (32, 'Broken pipe')
> ----------------------------------------

> I think the "bad starting read" message is a key, and it has to do
> with some very simple misconfiguration.

> Do you have any suggestions ?

> Thank you.

> Sincerely,
> Dmitry Dvoinikov
> http://www.targeted.org/

On Monday 24 May 2004 13.54, Dmitry Dvoinikov wrote:
> I think I found the bug that was causing weird behavior
> when connecting to localhost (see my previous message).
> It has to do with recent change to non-blocking connect -
>
> in svc.c, line 712:
> if(fcntl(sockfd, F_SETFL, flags | O_NONBLOCK) < 0) {
> should be
> if(fcntl(sockfd, F_SETFL, flags) < 0) {
> because we really don't want the connected socket to remain
> non-blocking.

Thanks for catching this Dmitry - I put a corrected -current on the Web site.

> I believe more testing is needed before declaring product like
> that "production stable".

If it's important to you maybe you should stick with the "stable" releases. We 
try to make -current as good as possible, but it's not always perfect.
-- 
Robert Segall
Apsis GmbH
Postfach, Uetikon am See, CH-8707
Tel: +41-1-920 4904

Robert,

> If it's important to you maybe you should stick with the "stable" releases.
We
> try to make -current as good as possible, but it's not always perfect.

Agree, I didn't realize I was handling -current.

Sincerely,
Dmitry Dvoinikov
http://www.targeted.org/

--- Original message follows ---

> On Monday 24 May 2004 13.54, Dmitry Dvoinikov wrote:
>> I think I found the bug that was causing weird behavior
>> when connecting to localhost (see my previous message).
>> It has to do with recent change to non-blocking connect -
>>
>> in svc.c, line 712:
>> if(fcntl(sockfd, F_SETFL, flags | O_NONBLOCK) < 0) {
>> should be
>> if(fcntl(sockfd, F_SETFL, flags) < 0) {
>> because we really don't want the connected socket to remain
>> non-blocking.

> Thanks for catching this Dmitry - I put a corrected -current on the Web site.

>> I believe more testing is needed before declaring product like
>> that "production stable".

> If it's important to you maybe you should stick with the "stable" releases.
We
> try to make -current as good as possible, but it's not always perfect.