Project

General

Profile

Actions

Bug #19597

closed

Unread request body causes truncated response

Added by Tom Clegg over 1 year ago. Updated over 1 year ago.

Status:
Resolved
Priority:
Normal
Assigned To:
Category:
API
Target version:
Story points:
0.5
Release relationship:
Auto

Description

wb2 testing has found that when sending request params to controller using content-type: multipart/form-data, the params are ignored, and sometimes the response is truncated.

2022/10/04 16:45:45 [error] 24852#24852: *138 recv() failed (104: Connection reset by peer) while sending to client, client: 10.2.3.4, server: pirca.arvadosapi.com, request: "POST /arvados/v1/users?_method=GET&limit=1000 HTTP/2.0", upstream: "http://127.0.0.1:8003/arvados/v1/users?_method=GET", host: "pirca.arvadosapi.com", referrer: "https://localhost:3000/" 
Possible explanation:
  • nginx proxies client request using content-type multipart/form-data
  • controller does not support multipart/form-data, and does not even read the request body
  • controller sends 200 response and hangs up
  • while forwarding the response to client, nginx gets a write error sending the request body (because controller hung up)
  • this is a protocol error, so nginx writes an error log and terminates the [http2] client connection

The Nginx error message "recv() failed while sending to client" sounds like the error originated on the client connection rather than the upstream connection, so the details might not be exactly right here, but nonetheless it seems likely the problem is caused by the unread request body.

Proposed fix: in (*router)loadRequestParams() in source:lib/controller/router/request.go, if request content-type is multipart/form-data, either read and parse the body accordingly, or error out and fail the request.


Files

19597-ParseMultipartForm-only.patch (839 Bytes) 19597-ParseMultipartForm-only.patch Brett Smith, 01/10/2023 11:41 PM

Subtasks 1 (0 open1 closed)

Task #19893: Review 19597-multipart-requestResolvedTom Clegg01/03/2023Actions
Actions #1

Updated by Tom Clegg over 1 year ago

  • Description updated (diff)
Actions #2

Updated by Tom Clegg over 1 year ago

  • Status changed from New to In Progress
  • Category set to API
Actions #4

Updated by Tom Clegg over 1 year ago

  • Target version set to 2023-01-18 sprint
Actions #5

Updated by Tom Clegg over 1 year ago

  • Story points set to 0.5
Actions #6

Updated by Brett Smith over 1 year ago

Tom Clegg wrote in #note-3:

19597-multipart-request @ 6742560001ba1db4d51e5bcd5333a0b04d07ca5c -- developer-run-tests: #3432

The docs for ParseMultipartForm say:

ParseMultipartForm calls ParseForm if necessary.

For simplicity's sake, does it make sense to promote your new code out of the block, like attached? The router tests all pass with this, including your new one.

Either way, this looks good to me.

Actions #7

Updated by Tom Clegg over 1 year ago

  • Status changed from In Progress to Resolved
Actions #8

Updated by Peter Amstutz over 1 year ago

  • Release set to 57
Actions

Also available in: Atom PDF