Hi!
I bumped - in production, alas - into an issue where certain browsers (Dolphin
HD for Android, for instance) got an empty response from uwsgi.
Looking at the logs, this was apparently caused by the security check on
plugins/http.c:474 (uwsgi-1.3-snapshot2):
if (c >= MAX_HTTP_VEC-4) {
uwsgi_log("too much headers in request. skipping it.\n");
return 0;
}
So, as an emergency patch, I changed MAX_HTTP_VEC from 128 to 512 and
recompiled the server binary. I noticed this same constant defines the number
of iovecs available per HTTP session as the (fairly cryptic) `uss' field in the
http session struct. (What's that anyway?)
I'm wondering: what problems, if any, might I expect to run into due to this
#define change?
I'm also seriously considering switching to have a "dummy" nginx in front of
uwsgi (that proxies all requests to uwsgi) in hopes of having a more robust
HTTP parser - would you think this would be a Good Idea? I'd like to keep the
server architecture as light as possible. (Another thought: One could perhaps
replace uwsgi's implementation of HTTP parsing with the seriously
tried-and-tested Joyent parser that in turn is based on the Nginx parser:
https://github.com/joyent/http-parser)
Thanks!
Aarni Koskela
_______________________________________________
uWSGI mailing list
[email protected]
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
