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?
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".
