> 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?)
It is Uwsgi Session Structure, practically the http parser of the router
already assemble a uwsgi packet for the backend in the form of an iov
list.
Raising that is a 'bet' as every system has a maximum value. I have
modified the code to get the IOV_MAX value from the system. By the way is
that kind of situation where you suddenly fail (writev() error) if you
have increased it too much. So if you got no error, 512 is good for your
system (linux system should support upto 1024 vectors)
>
> 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?
it depends on what you mean for 'robust'. I think you are talking about
'fully featured', and if it is the reason, well, nginx it is a good
choice.
But if you are targeting for a simple parser, the http router is a bit
faster. Honestly if you are using features like subscription system, the
http parser is a really good choice, but if you are only using it as a
shield, the advantages are very few.
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)
>
this is part of another project i am working on, related to uWSGI, but out
of its tree. Maybe it is the solution you are searching for... stay tuned
:)
--
Roberto De Ioris
http://unbit.it
_______________________________________________
uWSGI mailing list
[email protected]
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
