Fix mesh-forwarded image requests losing body data#367
Open
v-mwalk wants to merge 1 commit into
Open
Conversation
Three stacked bugs caused every image sent to a mesh-forwarded route (e.g. POST /v1/vision/detection) to arrive at the receiving server with no image data, whether from a real client or the mesh's own periodic route-probing: ForwardAsync() copied Content-Type/Content-Length onto HttpRequestMessage.Headers instead of Content.Headers, so HttpClient never sent a usable Content-Type (with multipart boundary) on the wire. The receiving Kestrel pipeline couldn't parse the body as multipart form data and Request.Form.Files came back empty. Forwarding exceptions were logged via Debug.WriteLine, a no-op in Release builds and never routed through CodeProject.AI's own log system, so failures were invisible. Wired DispatchRemoteRequest's catch block up to ILogger<ProxyController> instead, and surfaced ex.Message directly in the error response. With both above fixed, forwarding started throwing "Sent 0 request content bytes, but Content-Length promised NNNNN" - the request body stream was already consumed upstream by the time ForwardAsync() read it. Fixed by enabling request buffering as the first middleware in Startup.Configure() and rewinding the body position immediately before building the forwarded request. Also fixes dashboard's "Accepting Requests" line (both server-side in MeshSummary.cs and client-side in dashboard.js) read AllowRequestForwarding instead of AcceptForwardedRequests, so a receive-only mesh server showed as not accepting forwarded requests even while correctly processing them.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Three stacked bugs caused every image sent to a mesh-forwarded route (e.g. POST /v1/vision/detection) to arrive at the receiving server with no image data, whether from a real client or the mesh's own periodic route-probing:
ForwardAsync() copied Content-Type/Content-Length onto HttpRequestMessage.Headers instead of Content.Headers, so HttpClient never sent a usable Content-Type (with multipart boundary) on the wire. The receiving Kestrel pipeline couldn't parse the body as multipart form data and Request.Form.Files came back empty.
Forwarding exceptions were logged via Debug.WriteLine, a no-op in Release builds and never routed through CodeProject.AI's own log system, so failures were invisible. Wired DispatchRemoteRequest's catch block up to ILogger instead, and surfaced ex.Message directly in the error response.
With both above fixed, forwarding started throwing "Sent 0 request content bytes, but Content-Length promised NNNNN" - the request body stream was already consumed upstream by the time ForwardAsync() read it. Fixed by enabling request buffering as the first middleware in Startup.Configure() and rewinding the body position immediately before building the forwarded request.
Also fixes dashboard's "Accepting Requests" line (both server-side in MeshSummary.cs and client-side in dashboard.js) read AllowRequestForwarding instead of AcceptForwardedRequests, so a receive-only mesh server showed as not accepting forwarded requests even while correctly processing them.
FYI @ChrisMaunder :-)