Project

General

Profile

Bug #12713

civetweb frontend: response is buffered in memory if content length is not explicitly specified

Added by Radoslaw Zarzynski about 4 years ago. Updated 26 days ago.

Status:
Resolved
Priority:
High
Target version:
-
Start date:
08/17/2015
Due date:
% Done:

0%

Source:
other
Tags:
Backport:
mimic luminous
Regression:
No
Severity:
3 - minor
Reviewed:
Affected Versions:
ceph-qa-suite:
Pull request ID:

Description

If content length is not explicitly specified by upper layer through a call to RGWMongoose::send_content_length(), civetweb frontend performs extensive buffering in order to properly calculate the size of a content and attach the Content-Length HTTP header. Please take a look on RGWMongoose::write_data() and RGWMongoose::complete_request() methods.


Related issues

Copied to rgw - Backport #39614: mimic: civetweb frontend: response is buffered in memory if content length is not explicitly specified Resolved
Copied to rgw - Backport #39615: luminous: civetweb frontend: response is buffered in memory if content length is not explicitly specified Resolved

History

#1 Updated by Radoslaw Zarzynski about 4 years ago

  • Status changed from New to In Progress
  • Assignee set to Radoslaw Zarzynski

#2 Updated by Robin Johnson about 1 year ago

I have a workaround-level fix for this here:
https://github.com/ceph/ceph/pull/23940

It causes the FE to avoid the buffering rather than disable it outright.

#3 Updated by Casey Bodley 5 months ago

  • Status changed from In Progress to Pending Backport
  • Priority changed from Normal to High
  • Backport set to mimic luminous
  • Pull request ID set to 23940

#4 Updated by Nathan Cutler 5 months ago

  • Copied to Backport #39614: mimic: civetweb frontend: response is buffered in memory if content length is not explicitly specified added

#5 Updated by Nathan Cutler 5 months ago

  • Copied to Backport #39615: luminous: civetweb frontend: response is buffered in memory if content length is not explicitly specified added

#6 Updated by Nathan Cutler 26 days ago

  • Status changed from Pending Backport to Resolved

While running with --resolve-parent, the script "backport-create-issue" noticed that all backports of this issue are in status "Resolved".

Also available in: Atom PDF