0

This question might be related with Forward multipart/x-mixed-replace live stream ASP.NET Core, but while my situation is slighly different I openened a new question. I've followed all the suggestions and other questions / suggestions from other questions opened by TS from the mentioned question, without luck.

My controller uses a http client to request the RTSP stream from a camera to serve this to the api consumer. As of .net core2 this works fine on all systems. after upgrading / updating all code to .net 6 the camerastream isn't working any more on all systems. Some systems (based on the same Virtual Machine) show the stream, but other don't.

What i've done so far:

  • disabled authentication / ssl to be able to follow the streams
  • captured all requests by wireshark -- On a system the stream isn't working, when I close / abort the request the data is printed in the debug console, which looks fine -- On a system the stream isn't working i've seen once an IOException: The steam was too long. This suggests the copy of the stream from the http client talking to the camera to the output stream doesn't work, as if it's buffering before copied to the output stream. But, why does it then works on some systems, and on other not.... -I've added 'EnableRangeProcessing' without result.

The controller code looks like:

[ResponseCache(NoStore = true)]
public async Task<IActionResult> ImageStream(int cameraId, int maxfps = 30)
{
var stream = await _cameraService.GetCameraStreamAsync(cameraId, credentials, maxfps);

return new FileStreamResult(
  stream,
  "multipart/x-mixed-replace; boundary=\"myBoundary\"");
}

_cameraService:
public async Task<Stream> GetCameraStreamAsync(int cameraId, CameraCredentialsDto credentials, int maxFps)
        {
            var client = new HttpClient { BaseAddress = new Uri($"http://{credentials.IPaddress}") };
            client.SetBasicAuthentication(credentials.Username, credentials.Password);
            client.DefaultRequestHeaders.ExpectContinue = false;

            string relativeUrl = $"cameraSpecificURL";
            return await client.GetStreamAsync(relativeUrl);
        }

--update

I've compared the request headers of a working an non working system but there's from the client side no difference between the two requests.

GET /appapi/v1/camera/1003/stream?maxfps=30&token=**redacted** HTTP/1.1
Host: ipaddress:5001
Connection: keep-alive
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/116.0.0.0 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9,nl;q=0.8

Also the returned data is in correct format, the two dashes are in front of the new segment. Also by requesting the stream directly from the camera on a system the stream is not provided by the controller, the data from the camera is fine.

impeeNL
  • 21
  • 4
  • I would capture the body/header data of a HTTP request with same data on working and non working connection and compare. I think either the headers or body data is different. It could be default http headers or maybe the UserAgent Header. The attachments should be MIME and each attachment is a new line starting with two dashes : https://learn.microsoft.com/en-us/previous-versions/office/developer/exchange-server-2010/aa563375(v=exchg.140) – jdweng Aug 17 '23 at 12:29
  • thanks for the reaction, i've updated the question with the additional information. The only thing I assume what could happen is that copying of the stream fails for some reason, and that the controller waits for a full response or so. but why not consequently... – impeeNL Aug 17 '23 at 13:51
  • Does it work with small amounts of data? what is the status code in the response? I suspect the authentication method may of changes on the server to OAUTH2 on some servers and not others. Or the certificate changed. You are using signed exchange. See https://web.dev/signed-exchanges/ – jdweng Aug 17 '23 at 15:46
  • Thanks for pointing out. There is no issue regarding the auth, because i got the stream delivered from the camera. But, it triggers me to try to isolate the controller and http client to get the stream to a fresh .net 6 project and there it works in every scenario. So now I'm digging into differences between my production .net 6 project and the fresh project.... – impeeNL Aug 18 '23 at 09:00
  • The sniffer data is the key in solving this issue. Searching through code is the hard way and may not find the solution. I was a network engineer for 5 years and always discovered the answer through the sniffer. Especially when I could compare working and non working. Where you are getting exactly the same data from two different clients how can the client be the issue. Some client will try one type connection and when it fails retry with a different type. You may be getting two request from working system. – jdweng Aug 18 '23 at 09:35

1 Answers1

0

Well. figured out. It was just my code. We'd some spooky middleware (in dev) which inspects every request for logging purpose and rewinds the position of the body to 0. By removing this middleware it was fixed.

This comment triggers me: FileStreamResult in ASP.NET core of a large file ( > 2 GB) results in System.IO.IOException: Stream was too long

impeeNL
  • 21
  • 4