How to send a long url with get method to server - django

I have want to send a long url with GET, and I also need to add the url in the GET link,
like this(React):
let urlParam = {
apply_user: this.state.apply_user,
order_id: this.state.order_id,
begin_date: this.state.begin_date,
end_date: this.state.end_date,
status: this.state.status,
execute_mode: this.state.execute_mode,
page: page,
pageSize: this.state.pageSize,
otype:'all',
}
history.pushState(null, null, '?'+concatURLParams(urlParam))
then I can get all message from the url, like this :
http://cmdb.server.com/page/machine/list/?page=1&ips=172.17.10.3%20172.17.10.4%20172.17.10.9%20172.17.10.10
but in fact, the param is so long , there are lots of ip need to send.
And I use uwsgi to run my django project, I set buffer-size to 65536. official doc tell me the max size is 64k, but it got this, too.
invalid uwsgi request (current strsize: 21600). skip.
[pid: 15947|app: -1|req: -1/7] () {0 vars in 31 bytes} [Mon Jan 14 11:18:52 2019] => generated 0 bytes in 0 msecs ( 500) 0 headers in 0 bytes (0 switches on core 0)
this is my uwsgi.ini:
[uwsgi]
socket=127.0.0.1:9090
chdir=/home/ops/cmdb_futu/jumpserver
module=jumpserver.wsgi
master=true
buffer-size=65536
vacuum=true
processes=8
max-requests=2000
chmod-socket=664
vacuum=true
pidfile=uwsgi.pid
and I set nginx large_client_header_buffers and client_header_buffer_size to 64k, too.
But I don't make it for a long time. someone know why and help me.

Related

'no python application found' in Django

I tried to deploy my Django project on server with uwsgi.
I can initial uwsgi with uwsgi --ini conf/uwsgi.ini
But when I tried to visit the website, I got this error
--- no python application found, check your startup logs for errors ---
[pid: 11228|app: -1|req: -1/1] 127.0.0.1 () {46 vars in 946 bytes} [Mon Nov 28 17:06:37 2022] GET / => generated 21 bytes in 0 msecs (HTTP/1.1 500) 2 headers in 83 bytes (0 switches on core 0)
I put my repo at https://github.com/dolphinfafa/MyLife
Anyone knows how to resolve this?

How to disable request logging in Django and uWSGI?

My uWSGI logs are full of entries like this for every request:
localhost [pid: 4029|app: 0|req: 1/1] 127.0.0.1 () {48 vars in 906
bytes} [Wed Mar 23 18:35:38 2016] GET / => generated 94847 bytes in
1137 msecs (HTTP/1.1 200) 4 headers in 224 bytes (1 switches on core
0)
I'm not sure if it's uWSGI spamming them or Django. How can I disable the request logging?
What does your uwsgi.ini look like? That's where you'd want to disable logging.
Set: disable-logging=True
Here's the docs:
http://uwsgi-docs.readthedocs.org/en/latest/Options.html#disable-logging
Or from the console with:
uwsgi --disable-logging

Django + uWSGI hold a long time to response

I'm running a Django web application using Nginx and uWSGI. Now I meet a problem that the finish_process view in django
I have added logging at the begin and the end of Django finish_process view.
I make a request at 17:20:18, and the view finished at 17:20:48. But uWSGI does not return response at this time, and after 577 seconds, it throws IOError when it try to write response to client, because nginx close the connection (uwsgi_read_timeout is 300 seconds).
My question is why uWSGI holds the response so long after Django handled the view? I'm a bit at a loss.
Django log:
[INFO]246 views.py/finish_process 2016-03-06 17:20:18: [VIEW][START] finish_process: id=4
[INFO]282 views.py/finish_process 2016-03-06 17:20:48: [VIEW][END] finish_process: id=4
uWSGI log:
Sun Mar 6 17:29:55 2016 - uwsgi_response_writev_headers_and_body_do(): Broken pipe [core/writer.c line 296] during POST /api/finish_process/ (10.11.16.251)
IOError: write error
[pid: 3275|app: 0|req: 48689/48688] 10.11.16.251 () {34 vars in 553 bytes} [Sun Mar 6 17:20:18 2016] POST /api/finish_process/ => generated 0 bytes in 577024 msecs (HTTP/1.1 200) 3 headers in 0 bytes (0 switches on core 4)
Nginx error.log:
2016/03/06 17:25:18 [error] 3052#0: *44561 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 10.11.16.251, server: skyline, request: "POST /api/finish_process/ HTTP/1.1", upstream: "uwsgi://unix:/var/run/skyline.sock:", host: "10.11.16.253"
uwsgi.ini:
[uwsgi]
socket = /var/run/skyline.sock
chdir = /opt/skyline
processes = 1
threads = 10
master = true
env = DJANGO_SETTINGS_MODULE=skyline.prod_settings
module = skyline.wsgi:application
chmod-socket = 666
vacuum = true
die-on-term = true
Nginx conf:
server {
listen 80;
server_name skyline;
charset utf-8;
client_max_body_size 50M;
uwsgi_read_timeout 300;
location / {
include uwsgi_params;
uwsgi_pass unix:/var/run/skyline.sock;
}
}
Updated:
Solved. I made a mistake.

nginx & uwsgi deploy django app get SIGPIPE 502 error

I use nginx and uwsgi deploy my django webapp, the start few minutes all things well but after some time the ngnix will report 502 error and I check the uwsgi stderr log. there are some error marked => generated & SIGPIPE: writing to a closed pipe/socket/fd (probably the client disconnected) on request such as blow error message:
>[pid: 27427|app: 0|req: 1/1] 10.209.78.30 () {38 vars in 1030 bytes} [Mon Sep 29 15:46:00 2014] GET blabla...(just request url address) => generated 16018 bytes in 1428 msecs (HTTP/1.1 200) 6 headers in 157 bytes (1 switches on core 0)
Mon Sep 29 15:46:03 2014 - SIGPIPE: writing to a closed pipe/socket/fd (probably the client disconnected) on request blabla...(just request url address) (ip 10.209.78.30) !!!
Mon Sep 29 15:46:03 2014 - uwsgi_response_writev_headers_and_body_do(): Broken pipe [core/writer.c line 287] during GET blabla...(just request url address) (10.209.78.30)
IOError: write error
[pid: 27425|app: 0|req: 1/2] 10.209.78.30 () {38 vars in 2050 bytes} [Mon Sep 29 15:46:00 2014] GET blabla...(just request url address) => generated 0 bytes in 3578 msecs (HTTP/1.1 200) 6 headers in 0 bytes (0 switches on core 0)
Mon Sep 29 15:46:04 2014 - SIGPIPE: writing to a closed pipe/socket/fd (probably the client disconnected) on request blabla...(just request url address) (ip 10.217.95.130) !!!
Mon Sep 29 15:46:04 2014 - uwsgi_response_writev_headers_and_body_do(): Broken pipe [core/writer.c line 287] during GET blabla...(just request url address) (10.217.95.130)
IOError: write error
[pid: 27426|app: 0|req: 1/3] 10.217.95.130 () {38 vars in 1871 bytes} [Mon Sep 29 15:46:00 2014] GET blabla...(just request url address) => generated 0 bytes in 4415 msecs (HTTP/1.1 200) 6 headers in 0 bytes (0 switches on core 0)
Mon Sep 29 15:46:05 2014 - SIGPIPE: writing to a closed pipe/socket/fd (probably the client disconnected) on request blabla...(just request url address) (ip 10.217.95.130) !!!
Mon Sep 29 15:46:05 2014 - uwsgi_response_writev_headers_and_body_do(): Broken pipe [core/writer.c line 287] during GET blabla...(just request url address) (10.217.95.130)
IOError: write error
I replace the request url by blabla...
My nginx.conf is bleow:
location / {
add_header "Access-Control-Allow-Origin" "*";
add_header "Access-Control-Allow-Methods" "GET, OPTIONS";
add_header "Access-Control-Allow-Headers" "origin, authorization, accept";
uwsgi_pass unix:///tmp/djangoapp.sock;
include uwsgi_params;
}
uWSGI launch command:
uwsgi --socket /tmp/djangoapp.sock -p 10 --wsgi-file /opt/graphite/conf/graphite_wsgi.py --chmod-socket=666

Nginx connection reset, response from uWsgi lost

I have a django app hosted via Nginx and uWsgi. In a certain very simple request, I get different behaviour for GET and POST, which should not be the case.
The uWsgi daemon log:
[pid: 32454|app: 0|req: 5/17] 127.0.0.1 () {36 vars in 636 bytes} [Tue Oct 19 11:18:36 2010] POST /buy/76d4f520ae82e1dfd35564aed64a885b/a_2/10/ => generated 80 bytes in 3 msecs (HTTP/1.0 440) 1 headers in 76 bytes (0 async switches on async core 0)
[pid: 32455|app: 0|req: 5/18] 127.0.0.1 () {32 vars in 521 bytes} [Tue Oct 19 11:18:50 2010] GET /buy/76d4f520ae82e1dfd35564aed64a885b/a_2/10/ => generated 80 bytes in 3 msecs (HTTP/1.0 440) 1 headers in 76 bytes (0 async switches on async core 0)
The Nginx accesslog:
127.0.0.1 - - [19/Oct/2010:18:18:36 +0200] "POST /buy/76d4f520ae82e1dfd35564aed64a885b/a_2/10/ HTTP/1.0" 440 0 "-" "curl/7.19.5 (i486-pc-linux-gnu) libcurl/7.19.5 OpenSSL/0.9.8g zlib/1.2.3.3 libidn/1.15"
127.0.0.1 - - [19/Oct/2010:18:18:50 +0200] "GET /buy/76d4f520ae82e1dfd35564aed64a885b/a_2/10/ HTTP/1.0" 440 80 "-" "curl/7.19.5 (i486-pc-linux-gnu) libcurl/7.19.5 OpenSSL/0.9.8g zlib/1.2.3.3 libidn/1.15"
The Nginx errorlog:
2010/10/19 18:18:36 [error] 4615#0: *5 readv() failed (104: Connection reset by peer) while reading upstream, client: 127.0.0.1, server: localhost, request: "POST /buy/76d4f520ae82e1dfd35564aed64a885b/a_2/10/ HTTP/1.0", upstream: "uwsgi://unix:sock/uwsgi.sock:", host: "localhost:9201"
In essence, Nginx somewhere loses the response if I use POST, not so if I use GET.
Anybody knows something about that?
Pass --post-buffering 1 to uwsgi
This will automatically buffer all the http body > 1 byte
The problem is raised by the way nginx manages upstream disconnections
I hit the same issue, but on my case I can't disable "uwsgi_pass_request_body" as most times (but not always) my app do need the POST data.
This is the workaround I found, while this issue is not fixed in uwsgi:
http://permalink.gmane.org/gmane.comp.python.wsgi.uwsgi.general/813
import django.core.handlers.wsgi
class ForcePostHandler(django.core.handlers.wsgi.WSGIHandler):
"""Workaround for: http://lists.unbit.it/pipermail/uwsgi/2011-February/001395.html
"""
def get_response(self, request):
request.POST # force reading of POST data
return super(ForcePostHandler, self).get_response(request)
application = ForcePostHandler()
I am facing the same issues. I tried all solutions above, but they were not working. Ignoring the response body in my case is simply not an option.
Apparently it is a bug with nginx and uwsgi when dealing with POST requests whose response is smaller than 4052 bytes
What solved it for me was adding "--pep3333-input" to the parameter list of uwsgi. After that all POSTs are returned correctly.
Versions of nginx/uwsgi I'm using:
$ nginx -V
nginx: nginx version: nginx/0.9.6
$ uwsgi --version
uWSGI 0.9.7
After a lucky find in further research (http://answerpot.com/showthread.php?577619-Several%20Bugs/Page2) I found something that helped...
Supplying the uwsgi_pass_request_body off; parameter in the Nginx conf resolves this problem...