Middleware help to ignore/change a Request Content-Length (or possible Http1ContentLengthMessageBody bug) for FFMPEG and VLC support #64533
Unanswered
RogerHardiman
asked this question in
Q&A
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Hi,
I need to make Kestrel ignore the Content-Length in a HTTP POST Request, and read the Request Body forever (until the socket closes)
FFMPEG, VLC and SharpRTSP have a RTSP-Over-HTTP clients that uses a long running HTTP POST request with a Content Length of 32767 but then send more than 32767 bytes, which causes Kestrel to Throw an Exception.
Middleware to change the Content Length to UInt64.Max failed
By the time my Middleware was called, Kestrel has already parsed the Request Headers and created a Http1ContentLengthMessageBody with max size 32767.
Help Needed...
a) is this a Kestrel Bug? Perhaps if middleware changes the Content Length in a Request Header the Http1 Message Body needs updating.
b) or is there a way I can change the Request Header before Http1ContentLengthMessageBody_ is created.
Further info.
The RTSP-Over-HTTP spec is from Apple and dates back to 1999.
The HTTP POST is used to send RTSP commands to the RTSP-over-HTTP Server (eg DESCRIBE, SETUP, PLAY commands).
Apple's problem was that they had to guess how long the Content Length would be to reach the PLAY command and guessed at 32767 bytes.
Many ONVIF IP cameras now ask for Keepalive messages to be sent every 30 or 60 seconds and these also go up the HTTP POST.
So the problem I face is all these Keepalive messages keep using up some of the 32767 bytes of Content Length until they eventually exceed 32767 bytes.
I tested some real IP cameras. They all ignored the Content Length and read form the socket until the socket closes.
Thanks
Roger
Beta Was this translation helpful? Give feedback.
All reactions