Bug #3031: uwsgi fails with HTTP/2 - Lighttpd - lighty labs

Actions

Copy link

Bug #3031

closed

uwsgi fails with HTTP/2

Added by flynn over 3 years ago. Updated over 3 years ago.

Status:

Fixed

Priority:

Normal

Category:

mod_scgi

Target version:

1.4.56

ASK QUESTIONS IN Forums:

Description

Updating to the upcoming version 1.4.56 and enabling HTTP/2 my searx instance fails with a 502.

Using strace I found:
- lighttpd sets SERVER_PROTOCOL to HTTP/2 for the uwsgi request
- uwsgi itself answers with

read(20, "HTTP/2.0 200 OK\r\nContent-Type: text/html; charset=utf-8\r\nContent-Length: 10731\r\nServer-Timing: total;dur=92.483\r\n\r\n<!DOCTYPE html>\n<html xmlns=\"http://www.w3.org/1999/xhtml\" lang=\"de\" xml:lang=\"de\">\n<head>\n    <meta charset=\"UTF-8\" />\n    <meta name=\"description\" content=\"searx - a privacy-respecting, hackable metasearch engine\" />\n    <meta name=\"keywords\" content=\"searx, search, search engine, metasearch, meta search\" />\n    <meta http-equiv=\"X-UA-Compatible\" content=\"IE=edge\">\n    <meta name=\"generator\" content=\"searx/0.17.0\">\n    <meta name=\"referrer\" content=\"no-referrer\">\n    <meta name=\"viewport\" content=\"width=device-width, initial-scale=1 , maximum-scale=2.0, user-scalable=1\" />\n    <script src=\"/searx/translations.js\"></script>\n    <title>searx</title>\n    <link rel=\"stylesheet\" href=\"/searx/static/css/bootstrap.min.css\" type=\"text/css\" />\n    <link rel=\"stylesheet\" href=\"/searx/static/themes/oscar/css/logicodev.min.css\" type=\"text/css\" />\n    <link rel=\"stylesheet\" href=\"/searx/static/css/leaflet.min.css\" type=\"text/css\" />\n    <!-- HTML5 Shim and Respond.js IE8 support of HTML5 elements and media queries -->\n    <!--[if lt IE 9]>\n      <script src=\"/searx/static/js/html5shiv.min.js\"></script>\n      <script src=\"/searx/static/js/respond.min.js\"></script>\n    <![endif]-->\n\n    <link rel=\"shortcut icon\" href=\"/searx/static/themes/oscar/img/favicon.png\" />\n\n\n    <link title=\"searx\" type=\"application/opensearchdescription+xml\" rel=\"search\" href=\"/searx/opensearch.xml\"/>\n    <noscript>\n        <style type=\"text/css\">\n            .tab-content > .active_if_nojs, .active_if_nojs {display: block !important; visibility: visible !important;}\n            .margin_top_if_nojs {margin-top: 20px;}\n            .hide_if_nojs {display: none !important;overflow: hidden !important;}\n            .disabled_if_nojs {pointer-events: none; cursor: default; text-decoration: line-through;}\n        </style>\n    </noscript>\n</head>\n<body class=\"index_endpoint\" >\n<div class=\"searx-navbar\"><span class=\"instance pull-left\"><a href=\"/s"..., 19036) = 10846

which is not HTTP/2 conforming and is maybe the reason for lighttpd to send a 502.

PEP 3333 (https://www.python.org/dev/peps/pep-3333/) only mentions HTTP 1.0 and 1.1 for SERVER_PROTOCOL:

SERVER_PROTOCOL
    The version of the protocol the client used to send the request. Typically this will be something like "HTTP/1.0" or "HTTP/1.1" and may be used by the application to determine how to treat any HTTP request headers. (This variable should probably be called REQUEST_PROTOCOL, since it denotes the protocol used in the request, and is not necessarily the protocol that will be used in the server's response. However, for compatibility with CGI we have to keep the existing name.)

Maybe the protocol must be changed to HTTP/1.1 for uwsgi requests, like the proxy module does as far as I know.

P.S.: uwsgi runs without errors with HTTP/2 disabled.

Actions

Copy link

Updated by gstrauss over 3 years ago

Thanks for reporting this. This is a bug in uwsgi, but I'll think about a workaround in lighttpd.

Protocols that follow the CGI gateway interface should respond with "Status: xxx" in the CGI gateway interface response header.

Some web servers accept NPH (non-parsed header) responses -- which look like HTTP response headers -- from CGI gateway backends. lighttpd is one of those servers.

If uwsgi is going to return a NPH, then it should understand the protocol it is using. Instead, it appears that uwsgi naively reflects back SERVER_PROTOCOL in the uwsgi response, which happens to work for HTTP/1.0 and HTTP/1.1, but is incorrect for HTTP/2. SERVER_PROTOCOL is "The version of the protocol the client used to send the request." to the server (not to the uwsgi backend) If the uwsgi backend returns a NPH, it must properly indicate the protocol that uwsgi is using. "HTTP/2.0" is invalid.

Actions

Copy link