Standalone with HTTPS support in 1.3 stable responds in cleartext

[colinligertwood]

Using 1.3 stable as standalone server with HTTPS support, I can send requests to the server in HTTPS, but the responses come in cleartext. The logs report a successful HTTP/1.1 200, but tcpdump shows cleartext bodies.

My cert is self signed. I've also tried many different config variations. Using straight HTTP mode with everything else left the same works like a charm.

This generates a -- (Error code: ssl_error_rx_record_too_long) -- in firefox.

My config: http://pastebin.com/VGFuSNKN
Server debug log: http://pastebin.com/F8N9EHZb
Openssl s_client test results: http://pastebin.com/rGhD7SnF

[unbit]

can you try with HEAD, or can you remove the spawn of the non-https server on port 80 ? i suspect hook are not correctly set

[colinligertwood]

Hiya, thanks for the response, and for the great work you guys have done on uwsgi!

I've removed the http directive and get the same thing. I also get no response from s_client when I try and issue any HTTP commands. Here's the output from a HEAD followed by .

https://gist.github.com/3937635

Here's the output from the console if I hit it with a browser. It's sending HTTP/1.1. I don't know if that's an issue:

[pid: 18404|app: 0|req: 3/3] 192.168.56.1 () {36 vars in 586 bytes} [Mon Oct 22 18:12:30 2012] GET / => generated 5958 bytes in 80 msecs (HTTP/1.1 200) 2 headers in 73 bytes (1 switches on core 0)

and fetching a single static file instead of /

[pid: 31331|app: 0|req: -1/1] 192.168.56.1 () {36 vars in 626 bytes} [Mon Oct 22 18:21:36 2012] GET /static/css/style.css => generated 0 bytes in 6 msecs via sendfile() (HTTP/1.1 200) 2 headers in 88 bytes (0 switches on core 0)

which generates (Error code: ssl_error_rx_record_too_long) and shows the request being served successfully as cleartext, with tcpdump.

and the config:

;uWSGI instance configuration
[uwsgi]
ini = /etc/uwsgi.ini
master = true
socket = /var/run/uwsgi.sock
https = 0.0.0.0:443,/root/server.crt,/root/server.key
http-to = /var/run/uwsgi.sock
python-path = /usr/local/ph
check-static = /usr/local/ph/www
wsgi-file = /usr/local/ph/www/wsgi_app.py
show-config = true
;end of configuration

This is all running on openbsd5.1. Standalone works great if I don't use HTTPS. Let me know if there's anything else I can do to help. I'm working on the UI for a network appliance and I'd love to be able to use uwsgi standalone instead of through a webserver.

Cheers!
Colin.

[unbit]

it looks like a openbsd-specific issue (maybe openssl-related) i will address it as soon as possibile.

Thanks for the report

[unbit]

Just tried current HEAD on OpenBSD 5.1 and it works normally, can you try that ?

[colinligertwood]

I've tried several of the latest snapshots and it behaves differently since the 1.4 tag. It looks like it's encrypting, but it doesn't send me any data. Empty response. Here's the console output with the config: https://gist.github.com/3940523
HTTP doesn't work either in this build. Same problem, empty response. Can you show me what you're doing to test it? If I can start with that, hopefully I can find the problem.

[colinligertwood]

Breakthrough! I've got 1.3-stable working with the following config: https://gist.github.com/3940995 1.4 still doesn't work, but that's ok :) I'm running without any socket communication. Just direct http.

[unbit]

just found a bug in kqueue, now HEAD should work. --https-to-http does not work in HEAD, i will port it tomorrow. Let me know if other things works on OpenBSD. Thanks a lot

[colinligertwood]

Will do. Thanks for the help. BTW, I've forked uwsgi and included a plugin I wrote to implement hosts_access as a router. Please have a look!

https://github.com/brainbitsca/uwsgi/tree/master/plugins/router_access

[unbit]

great, i will put comments on 'gray' areas, then feel free to make a pull request