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 be defined but then never used. Do you want a new patch for that, or is
it easier for
you guys to just go ahead and do that on your end?
Please send an updated patch.
Thanks,
Marton
On Sun, May 10, 2020 at 2:17 AM Marton Balint <c...@passwd.hu> wrote:
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-coded to 4k bytes in libavformat/internal.h,
> this causes ffmpeg to terminate the connection early, even though the
HTTP
> request is otherwise perfectly valid.
If that is the case then BUFFER_SIZE should be increased instead to
(MAX_URL_SIZE + HTTP_HEADERS_SIZE) at http.c, no?
Thanks,
Marton
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
