> Thanks for the reply, Roberto! > > However, is there a reason that I just don't get for MAX_HTTP_VEC to be > directly linked to the size of `uss'? > struct iovec iov[MAX_HTTP_VEC]; > char uss[MAX_HTTP_VEC * 2]; > I mean, I understand that each piece of an HTTP request is parsed into a > different iovec, and that 128 should be plenty for those... but as I > understood, the iovecs point into `uss'? > MAX_HTTP_VEC would then limit it to 128 pieces (iovecs) of request at a > time, and 128*2=256 bytes of (uwsgi-protocol) request altogether? Or am I > misunderstanding things?
uss does not contains strings, it only contains their length. It is mapped as char*2 (16bit) as 65536 is the maximum size of a uwsgi string (i do not use uint16_t just for avoiding heavy typecasting later). So: session->iov contains the pointers to strings session->uss contains the pointer for their size. I need two buffers, as string sizes tend to change (Host -> HTTP_HOST for example) > > And by "robust" I don't mean "fully-featured" per se -- our app doesn't do > anything fancy, just GETs and POSTs, not even response streaming or > anything. Just something that I could depend on not to suddenly drop > requests without response (I guess returning a 500 Infernal Server Terror > would be kinder?)... Honestly i do not know why it does not return 500... it is the logic (and expected) thing... I will check it. -- Roberto De Ioris http://unbit.it _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
