Re: [uWSGI] handling large request payloads on a small number of endpoints

2018-02-15 Thread Roberto De Ioris

> we have a few HTTP endpoints that have very large request payloads
> (headers + query string).  They’re all oAuth endpoints coming in from 3rd
> parties, with a bunch of header data and a super long query string.
>
> the quick fix was to double buffer-size to 8192
>
> is this the best approach?

Yes, absolutely

>
> also, it might be worth adding to the “ThinkToKnow” docs that if you’re
> doing anything with oAuth against twitter or Facebook, you should increase
> the buffer size.  one (or more) platforms had some recent change where
> they either increased logging headers or increased their key size, and the
> payloads jumped to just-over 4100 bytes.

i agree, waiting for your pull request in uwsgi-docs :)

-- 
Roberto De Ioris
http://unbit.com
___
uWSGI mailing list
uWSGI@lists.unbit.it
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi


Re: [uWSGI] handling large request payloads on a small number of endpoints

2018-02-14 Thread jonathan vanasco

> On Feb 14, 2018, at 1:08 PM, jonathan vanasco  wrote:
> 
> also, it might be worth adding to the “ThinkToKnow” docs that if you’re doing 
> anything with oAuth against twitter or Facebook, you should increase the 
> buffer size.  one (or more) platforms had some recent change where they 
> either increased logging headers or increased their key size, and the 
> payloads jumped to just-over 4100 bytes.

scratch that.

I just finished reading through all their change logs and our change logs.  i 
should have caught this - the extra headers were debug cookies introduced by 
someone on our end.

___
uWSGI mailing list
uWSGI@lists.unbit.it
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi


[uWSGI] handling large request payloads on a small number of endpoints

2018-02-14 Thread jonathan vanasco
we have a few HTTP endpoints that have very large request payloads (headers + 
query string).  They’re all oAuth endpoints coming in from 3rd parties, with a 
bunch of header data and a super long query string.  

the quick fix was to double buffer-size to 8192

is this the best approach?

also, it might be worth adding to the “ThinkToKnow” docs that if you’re doing 
anything with oAuth against twitter or Facebook, you should increase the buffer 
size.  one (or more) platforms had some recent change where they either 
increased logging headers or increased their key size, and the payloads jumped 
to just-over 4100 bytes.
___
uWSGI mailing list
uWSGI@lists.unbit.it
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi