Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Fix Content-Range response when body size equals expected range length #28

Open
wants to merge 1 commit into
base: 2.2.x
Choose a base branch
from
Open

Fix Content-Range response when body size equals expected range length #28

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion src/Emitter/SapiStreamEmitter.php
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -86,7 +86,7 @@ private function emitBodyRange(array $range, ResponseInterface $response): void
$length = $last - $first + 1;

if ($body->isSeekable()) {
$body->seek($first);
$body->seek($body->getSize() === $length ? 0 : $first);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be ===, or <=? In other words, what hapepns when the body size is shorter than the requested length?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In that case, I think that the code should throw an exception but I preferred to make the minimal edition to fix #22 without modifying any other execution path.

We can fix that case in another PR.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After thinking about this, definitely, we should throw an exception in that case.

When the emitter receives a response object with a Content-Range header, we only have two options here:

  1. The response producer computes the Content-Range header and delegates to the emitter the responsibility of fixing the body content length.
  2. The response producer computes the Content-Range header and fixes the response body content so the received body size equals the length defined in the Content-Range header. (option fixed by this PR).

In the first case, the body size can be greater, equal, or lesser than the length defined in the Content-Range header. If the given body size is lesser than the length defined in the Content-Range header, the response producer failed at computing the Content-Range header and we should throw an exception.

Anyway, as I wrote previously, this PR only fixes option 2 but does not modify any behavior related to option 1, so I think it can be merged safely, and fix the problem with shorter body size in other PR.

@weierophinney What do you think?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

About exceptions: would that leave the door open for DDoS attacks? Having an app crash (on purpose) via generic header manipulation can be problematic.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You are right: throwing an exception could be a bad idea here. Maybe we can return a 502 response instead because the emitter got an invalid response.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we're trying to solve the problem at the wrong level.
The root of the problem is that the emitter doesn't have the full context to provide the correct range split (this comes on the request only).

If approaching this from a generic PoV (as we currently do), a middleware would be more suitable for parsing the requested ranges and converting the headers/body to provide support for single and multiple ranges.

Trying to make the emitter limit the body but also ignore things if the body was already truncated sounds unnecessary. To me, the emitter should focus on doing a single job: stream the response.

I'd suggest we create a new SapiStreamEmitter that doesn't do anything with Content-Range and deprecate the current one. We should also ask ourselves if the responsibility of parsing ranges and limiting the body belongs to this library.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree 💯 with @lcobucci here, and would gladly accept a PR that:

  • Creates a new SapiStreamEmitter implementation that doesn't do anything with the Content-Range header.
  • Deprecates the current SapiStreamEmitter.
  • Creates middleware for managing ranges.


$first = 0;
}
Expand Down
27 changes: 27 additions & 0 deletions test/Emitter/SapiStreamEmitterTest.php
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -608,6 +608,33 @@ public function testContentRange(string $header, string $body, string $expected)
self::assertSame($expected, ob_get_clean());
}

/**
* @psalm-return array<array-key, array{0: string, 1: string, 2: string}>
*/
public function ignoreContentRangeProvider(): array
{
return [
['bytes 0-2/*', 'Hel', 'Hel'],
['bytes 3-6/*', 'lo w', 'lo w'],
['items 0-0/1', 'Hello world', 'Hello world'],
];
}

/**
* @dataProvider ignoreContentRangeProvider
*/
public function testIgnoreContentRange(string $header, string $body, string $expected): void
{
$response = (new Response())
->withHeader('Content-Range', $header);

$response->getBody()->write($body);

ob_start();
$this->emitter->emit($response);
self::assertSame($expected, ob_get_clean());
}

public function testContentRangeUnseekableBody(): void
{
$body = new CallbackStream(function () {
Expand Down