# Websockets support for uwsgi protocol **URL:** \ **Category:** NGINX\ **Created:** [February 20, 2013, 2:31pm UTC](https://www.ruby-forum.com/t/websockets-support-for-uwsgi-protocol/226754 "2013-02-20T14:31:27Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![Roberto\_De\_Ioris](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/50afbb/32.png) [@Roberto\_De\_Ioris](https://www.ruby-forum.com/u/Roberto_De_Ioris)\ **Post date:** [February 20, 2013, 2:31pm UTC](https://www.ruby-forum.com/t/websockets-support-for-uwsgi-protocol/226754/1 "2013-02-20T14:31:27Z")
Hi, the (tiny) attached patch enable support for new websockets handling when the uwsgi protocol is used instead of HTTP. I have tested it with various websocket libraries and with the api available in uWSGI 1.9. From 1.9 sources (with nginx pointing to uwsgi port 3031): ./uwsgi -s :3031 -w tests.websockets\_echo --gevent 10 no additional configuration is needed for nginx ---
**Author:** ![Roberto\_De\_Ioris](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/50afbb/32.png) [@Roberto\_De\_Ioris](https://www.ruby-forum.com/u/Roberto_De_Ioris)\ **Post date:** [February 20, 2013, 2:51pm UTC](https://www.ruby-forum.com/t/websockets-support-for-uwsgi-protocol/226754/2 "2013-02-20T14:51:19Z")
Hello! (Cc’d nginx-devel@ as this is better list for this discussion.) On Wed, Feb 20, 2013 at 02:30:38PM +0100, Roberto De Ioris wrote: > no additional configuration is needed for nginx Should we also do the same for SCGI? I personally think it is more or less the same for all CGI-based protocols, and the only problematic one is FastCGI, which probably still needs wrapping within FCGI\_STDIN/FCGI\_STDOUT records instead of real connection upgrade. – Maxim D. > **[F5 NGINX: Built for cloud-native apps. Ready for AI traffic.](https://www.f5.com/products/nginx)** > > Deliver modern applications with NGINX. Explore high-performance load balancing, API gateways, and web server solutions trusted by top global enterprises. ---
**Author:** ![Roberto\_De\_Ioris](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/50afbb/32.png) [@Roberto\_De\_Ioris](https://www.ruby-forum.com/u/Roberto_De_Ioris)\ **Post date:** [February 20, 2013, 2:53pm UTC](https://www.ruby-forum.com/t/websockets-support-for-uwsgi-protocol/226754/3 "2013-02-20T14:53:40Z")
> > available in uWSGI 1.9. > > I personally think it is more or less the same for all CGI-based > > protocols, and the only problematic one is FastCGI, which probably > > still needs wrapping within FCGI\_STDIN/FCGI\_STDOUT records instead > > of real connection upgrade. AFAIK scgi body management works in the same way as the uwsgi one, so the patch should be usable there too – Roberto De Ioris > **[unbit - Overview](https://github.com/unbit)** > > makers of uWSGI and many more open source projects - unbit ---
**Author:** ![Roberto\_De\_Ioris](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/50afbb/32.png) [@Roberto\_De\_Ioris](https://www.ruby-forum.com/u/Roberto_De_Ioris)\ **Post date:** [February 20, 2013, 3:08pm UTC](https://www.ruby-forum.com/t/websockets-support-for-uwsgi-protocol/226754/4 "2013-02-20T15:08:17Z")
> > > > > > > Should we also do the same for SCGI? > > > > I personally think it is more or less the same for all CGI-based > > protocols, and the only problematic one is FastCGI, which probably > > still needs wrapping within FCGI\_STDIN/FCGI\_STDOUT records instead > > of real connection upgrade. > > AFAIK scgi body management works in the same way as the uwsgi one, so the > patch should be usable there too Ok, i can confirm the same patch applied to the SCGI module in the same position works (at least with uWSGI 1.9 in SCGI mode) ./uwsgi --scgi-nph-socket :3031 -w tests.websockets\_echo --gevent 10 remember to add scgi\_param PATH\_INFO $document\_uri; to the nginx config to make it work – Roberto De Ioris > **[unbit - Overview](https://github.com/unbit)** > > makers of uWSGI and many more open source projects - unbit ---
**Author:** ![Roberto\_De\_Ioris](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/50afbb/32.png) [@Roberto\_De\_Ioris](https://www.ruby-forum.com/u/Roberto_De_Ioris)\ **Post date:** [February 20, 2013, 4:12pm UTC](https://www.ruby-forum.com/t/websockets-support-for-uwsgi-protocol/226754/5 "2013-02-20T16:12:36Z")
Hello! On Wed, Feb 20, 2013 at 03:07:53PM +0100, Roberto De Ioris wrote: > > > > when the uwsgi protocol is used instead of HTTP. > > > > patch should be usable there too > > to the nginx config to make it work Ok, so the next question is: any specific reason to exclude normal CGI responses with “Status” as in your patch? I in fact don’t like the idea of supporting http-like answers with status like from CGI-like protocols, correct way is to use “Status” header. Not sure why Manlio introduced it at all, probably due to some compatibility concerns (and due to the fact that SCGI specification explicitly refuses to specify response format). Something like this should be better, IMHO: diff --git a/src/http/modules/ngx\_http\_scgi\_module.c b/src/http/modules/ngx\_http\_scgi\_module.c — a/src/http/modules/ngx\_http\_scgi\_module.c +++ b/src/http/modules/ngx\_http\_scgi\_module.c @@ -984,7 +984,7 @@ ngx\_http\_scgi\_process\_header(ngx\_http\_re u = r-\>upstream; ``` if (u->headers_in.status_n) { ``` - ``` return NGX_OK; ``` - ``` goto done; } if (u->headers_in.status) { ``` @@ -1015,6 +1015,14 @@ ngx\_http\_scgi\_process\_header(ngx\_http\_re u-\>state-\>status = u-\>headers\_in.status\_n; } - ``` done: ``` - - ``` if (u->headers_in.status_n == NGX_HTTP_SWITCHING_PROTOCOLS ``` - ``` && r->headers_in.upgrade) ``` - ``` { ``` - ``` u->upgrade = 1; ``` - ``` } ``` - ``` return NGX_OK; } ``` diff --git a/src/http/modules/ngx\_http\_uwsgi\_module.c b/src/http/modules/ngx\_http\_uwsgi\_module.c — a/src/http/modules/ngx\_http\_uwsgi\_module.c +++ b/src/http/modules/ngx\_http\_uwsgi\_module.c @@ -1018,7 +1018,7 @@ ngx\_http\_uwsgi\_process\_header(ngx\_http\_r u = r-\>upstream; ``` if (u->headers_in.status_n) { ``` - ``` return NGX_OK; ``` - ``` goto done; } if (u->headers_in.status) { ``` @@ -1049,6 +1049,14 @@ ngx\_http\_uwsgi\_process\_header(ngx\_http\_r u-\>state-\>status = u-\>headers\_in.status\_n; } - ``` done: ``` - - ``` if (u->headers_in.status_n == NGX_HTTP_SWITCHING_PROTOCOLS ``` - ``` && r->headers_in.upgrade) ``` - ``` { ``` - ``` u->upgrade = 1; ``` - ``` } ``` - ``` return NGX_OK; } ``` – Maxim D. > **[F5 NGINX: Built for cloud-native apps. Ready for AI traffic.](https://www.f5.com/products/nginx)** > > Deliver modern applications with NGINX. Explore high-performance load balancing, API gateways, and web server solutions trusted by top global enterprises. ---
**Author:** ![Roberto\_De\_Ioris](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/50afbb/32.png) [@Roberto\_De\_Ioris](https://www.ruby-forum.com/u/Roberto_De_Ioris)\ **Post date:** [February 20, 2013, 5:42pm UTC](https://www.ruby-forum.com/t/websockets-support-for-uwsgi-protocol/226754/6 "2013-02-20T17:42:03Z")
Hello! On Wed, Feb 20, 2013 at 04:20:29PM +0100, Roberto De Ioris wrote: > > format). > > Honestly i do not remember why Manlio added support for nph (but i have > added it to uWSGI SCGI parser too, so in my subconsciuous there should be > a good reason :P) > > regarding your updated patch is better for sure Committed, thnx. – Maxim D. > **[F5 NGINX: Built for cloud-native apps. Ready for AI traffic.](https://www.f5.com/products/nginx)** > > Deliver modern applications with NGINX. Explore high-performance load balancing, API gateways, and web server solutions trusted by top global enterprises. ---
**Author:** ![Roberto\_De\_Ioris](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/50afbb/32.png) [@Roberto\_De\_Ioris](https://www.ruby-forum.com/u/Roberto_De_Ioris)\ **Post date:** [February 20, 2013, 4:21pm UTC](https://www.ruby-forum.com/t/websockets-support-for-uwsgi-protocol/226754/7 "2013-02-20T16:21:22Z")
> Ok, so the next question is: any specific reason to exclude normal > CGI responses with “Status” as in your patch? > > I in fact don’t like the idea of supporting http-like answers with > status like from CGI-like protocols, correct way is to use > “Status” header. Not sure why Manlio introduced it at all, > probably due to some compatibility concerns (and due to the fact > that SCGI specification explicitly refuses to specify response > format). Honestly i do not remember why Manlio added support for nph (but i have added it to uWSGI SCGI parser too, so in my subconsciuous there should be a good reason :P) regarding your updated patch is better for sure – Roberto De Ioris > **[unbit - Overview](https://github.com/unbit)** > > makers of uWSGI and many more open source projects - unbit