On Sun, 10 May 2020, Joey Smith wrote:
Updated patch attached
Thanks, applied.
Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpe
Updated patch attached
On Sun, May 10, 2020 at 3:19 AM Marton Balint wrote:
>
>
> On Sun, 10 May 2020, Joey Smith wrote:
>
> > Actually, that seems like a more rational fix all around - I just saw the
> > BUFFER_SIZE in
> > http.c being limited to MAX_URL_SIZE and jumped straight to expanding
>
On Sun, 10 May 2020, Joey Smith wrote:
Actually, that seems like a more rational fix all around - I just saw the
BUFFER_SIZE in
http.c being limited to MAX_URL_SIZE and jumped straight to expanding that,
but in
looking at your suggestion, I see now there's an HTTP_HEADERS_SIZE that
appears
to
Actually, that seems like a more rational fix all around - I just saw the
BUFFER_SIZE in
http.c being limited to MAX_URL_SIZE and jumped straight to expanding that,
but in
looking at your suggestion, I see now there's an HTTP_HEADERS_SIZE that
appears
to be defined but then never used. Do you want
On Sun, 10 May 2020, Joey Smith wrote:
Some real-world sites use an authorization header with a bearer token; when
combined with lengthy request parameters to identify the video segment,
it's rather trivial these days to have a request body of more than 4k bytes.
Because MAX_URL_SIZE is hard-
Some real-world sites use an authorization header with a bearer token; when
combined with lengthy request parameters to identify the video segment,
it's rather trivial these days to have a request body of more than 4k bytes.
Because MAX_URL_SIZE is hard-coded to 4k bytes in libavformat/internal.h,
