We’ve been using a proxy route to post data from Notehub to an IIS web interface on our servers. This has worked without issue for months, but suddenly on 2/3 at 11 am CST, the interface has only been receiving blank request bodies. It correctly receives and logs the headers of the notes, but the body is logged only as “ “. Nothing on the side of the interface should have changed for this issue to begin occurring, and I’ve been able to test with a webhook that Notehub is in fact sending the binary data. Did something change on the Notehub.io side of things that would have broken the interface’s ability to correctly parse and read request bodies?
1 Like
I did some snooping with Wireshark + switched the route to point towards http instead of https, to make my search easier. Looks like we are receiving the body of the request at our server, but the ASP .NET IIS is for some reason receiving an empty request body of length zero.
Doing some research on ASP .NET 6 and HTTPs POST requests, it appears that a known issue is with the HTTPs header “Transfer-encoding: chunked“ causing request bodies to be empty.
Did Notehub recently update its HTTPs web.post to pass “Transfer-encoding: chunked” instead of using the default value of “identity”? Is there a way for us to overwrite this header, just like how it’s possible to overwrite the User-Agent?
Thank you!
Screenshot from Wireshark
1 Like
Thank you for diagnosing this issue. We added support for larger web.post payloads on Feb 3rd. You are correct that we are adding Transfer-Encoding: Chunked even to requests where it’s not needed. We are looking at fixing this ASAP.
I just want to confirm: are you sending binary data in the body field?
As documented here: web Requests - API Reference - IoT Connectivity at Blues
you should be sending binary data in the payload field instead.
Are you able to try that? I’d like to verify whether your binary data is routed correctly if it’s attached to the payload field instead of body.
Assuming you are indeed sending it as payload, we may have identified an issue that would cause this. We are investigating a fix. Unfortunately, it may take us until the beginning of next week to correct the issue.
UPDATE - Anna was able to modify the way we parsed the stream to get it working again so original request to roll back code on Blues side is retracted.
Original Post - Thanks for the productive dialogue. Here are Stemco, we are looking for as fast a solution as possible. Can you roll back your code to prior to February 3rd to get the system running as it was again (And then work on your corrections for whatever timeline is needed) so we can get all of our customers operational again?
Hi,
We’re following the procedure outlined in your tutorial. The code snippet in the screenshot below shows how we’re doing the upload.
I was able to get a fix in place on our side! I’ve removed the dependency on the content-length header and am now using a MemoryStream object in C# to read the entire payload before converting it to a byte array. We are finally receiving the entire body of the web.post request again with our API.
Thank you for the help!
2 Likes
I’m glad you were able to update your code to handle the chunked encoding.
I agree that for simple payloads, we do not need to use chunked encoding. We will make the change to use Content-Length instead.
Given that you have a workaround and that this is not impacting other customers, we expect to release this change next week. My apologies that this change impacted you.