View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0004838 | Taler | deployment and operations | public | 2016-12-13 17:46 | 2018-04-15 18:36 |
| Reporter | Marcello Stanisci | Assigned To | Florian Dold | Resolution deadline | |
| Implementer | Reviewer | ||||
| Release signed by | Deployed by | ||||
| Verifier | Communicator | ||||
| Data protection authority notification required | No | ||||
| CSIRT notification required | No | ||||
| Estimated effort (hours) | Actual effort (hours) | 0 | |||
| Fast-track | No | ||||
| Work package | none | ||||
| Priority | normal | Severity | minor | Reproducibility | have not tried |
| Status | closed | Resolution | fixed | ||
| Product Version | git (master) | ||||
| Target Version | 0.5 | Fixed in Version | 0.5 | ||
| Summary | 0004838: nginx polluting errors | ||||
| Description | Sometimes, for example when a request from a frontend to the backend takes too long to return, nginx returns (to the frontend) its own "502 Bad gateway" error having in the body the classic HTML page "Bad gateway" page. This interferes with error management because the frontend always expects an error to be in JSON format (or at least never HTML), as the backend would normally do. | ||||
| Steps To Reproduce | In the backoffice interface, try to track a WTID against a non existent exchange. Before the backend figures out that the given exchange doesn't exist, nginx will "inject" its own (502) error and return it to the frontend. | ||||
| Additional Information | The effect of this bug, affecting BackendError exceptions. INFO:talerfrontends.common_routes:serving /track/transfer, K2FZAHSCNJBTHRD94FHNVG7811WKCH8AHF6C25PRZGGQ1BTCJ22G/http://blonsa/Taler INFO:requests.packages.urllib3.connectionpool:Starting new HTTP connection (1): localshop ERROR:talerfrontends.helpers:failed to GET to 'http://localshop/track/transfer' INFO:talerfrontends.helpers:<html> <head><title>502 Bad Gateway</title></head> <body bgcolor="white"> <center><h1>502 Bad Gateway</h1></center> <hr><center>nginx/1.10.1</center> </body> </html> Traceback (most recent call last): File "/home/marcello/.local/lib/python3.5/site-packages/flask/app.py", line 2000, in __call__ return self.wsgi_app(environ, start_response) File "/home/marcello/.local/lib/python3.5/site-packages/flask/app.py", line 1991, in wsgi_app response = self.make_response(self.handle_exception(e)) File "/home/marcello/.local/lib/python3.5/site-packages/flask/app.py", line 1567, in handle_exception reraise(exc_type, exc_value, tb) File "/home/marcello/.local/lib/python3.5/site-packages/flask/_compat.py", line 33, in reraise raise value File "/home/marcello/.local/lib/python3.5/site-packages/flask/app.py", line 1988, in wsgi_app response = self.full_dispatch_request() File "/home/marcello/.local/lib/python3.5/site-packages/flask/app.py", line 1641, in full_dispatch_request rv = self.handle_user_exception(e) File "/home/marcello/.local/lib/python3.5/site-packages/flask/app.py", line 1545, in handle_user_exception return handler(e) File "/home/marcello/merchant-frontends/talerfrontends/helpers.py", line 343, in handle_backend_error jerror = json.loads(error.response) File "/usr/lib/python3.5/json/__init__.py", line 319, in loads return _default_decoder.decode(s) File "/usr/lib/python3.5/json/decoder.py", line 339, in decode obj, end = self.raw_decode(s, idx=_w(s, 0).end()) File "/usr/lib/python3.5/json/decoder.py", line 357, in raw_decode raise JSONDecodeError("Expecting value", s, err.value) from None json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0) 13/Dec/2016:18:37:23 +0100 HTTP/1.1 GET /track/transfer?wtid=K2FZAHSCNJBTHRD94FHNVG7811WKCH8AHF6C25PRZGGQ1BTCJ22G&exchange-uri=http%3A%2F%2Fblonsa&instance=Taler HTTP/1.1 => 500 | ||||
| Tags | No tags attached. | ||||
| Running the frontend without a backend should also reproduce that. | |
| The frontends now handle this properly, we simply check if we can parse the response as JSON. In fact all frontends *have* to handle this, since in real world deployments we don't control error pages, there might be some load balancer or reverse proxy that gives a non-JSON error page, that's completely normal. By making NGINX return error pages in JSON form we'd just get problems down the line later when we don't handle this properly. | |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2016-12-13 17:46 | Marcello Stanisci | New Issue | |
| 2016-12-13 17:46 | Marcello Stanisci | Assigned To | => Marcello Stanisci |
| 2016-12-13 17:46 | Marcello Stanisci | Status | new => assigned |
| 2016-12-21 16:57 | Marcello Stanisci | Note Added: 0011603 | |
| 2018-01-30 07:35 | Christian Grothoff | Product Version | => git (master) |
| 2018-01-30 07:35 | Christian Grothoff | Target Version | => 0.6 |
| 2018-01-31 17:54 | Florian Dold | Assigned To | Marcello Stanisci => Florian Dold |
| 2018-01-31 17:54 | Florian Dold | Status | assigned => informing |
| 2018-01-31 17:54 | Florian Dold | Resolution | open => fixed |
| 2018-01-31 17:54 | Florian Dold | Note Added: 0012845 | |
| 2018-01-31 17:54 | Florian Dold | Target Version | 0.6 => 0.5 |
| 2018-04-15 18:35 | Christian Grothoff | Fixed in Version | => 0.5 |
| 2018-04-15 18:36 | Christian Grothoff | Status | informing => closed |