Skip to content

Content length buffered sink #70

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.

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

Conversation

WyriHaximus
Copy link
Member

@WyriHaximus WyriHaximus commented Sep 27, 2016

This PR paves the way for the #69

@WyriHaximus WyriHaximus mentioned this pull request Sep 27, 2016
7 tasks
/**
* @var string
*/
protected $buffer = '';

Choose a reason for hiding this comment

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

Why not private?

Copy link
Member Author

Choose a reason for hiding this comment

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

You're right, protected has become a force of habit. Updated all protected properties to private.

Choose a reason for hiding this comment

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

Nice :)

Copy link

@marcj marcj Oct 10, 2016

Choose a reason for hiding this comment

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

Please let it protected. There's no need to make it private except you want to explicitly forbid to reuse your code, which is mostly not needed.

Copy link
Member

Choose a reason for hiding this comment

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

This class is marked as @internal, it will only be used internally and not exposed in our documentation, so this is not something others should rely and/or build on.

/**
* @var int
*/
protected $length;

Choose a reason for hiding this comment

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

Why not private?

Copy link
Member Author

Choose a reason for hiding this comment

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

Same as above 😄 .

@clue
Copy link
Member

clue commented Sep 28, 2016

This could use some documentation. What is this used for? When should this be used? Is this only used internally (@internal)?

@WyriHaximus
Copy link
Member Author

@clue Updated the PR with documentation, plus reworked some parts of the sink.

@@ -8,7 +8,8 @@
"guzzlehttp/psr7": "^1.0",
"react/socket": "^0.4",
"react/stream": "^0.4",
"evenement/evenement": "^2.0"
"evenement/evenement": "^2.0",
"react/promise": "^2.0 || ^1.0"

Choose a reason for hiding this comment

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

Why this?

Copy link
Member Author

Choose a reason for hiding this comment

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

Because the sink relies on promises and since 2.1 and 1.2 both introduce cancelable promises plus their API is compatible either is required for wider compatibility. When @jsor releases 3.0 I'll have to research it to see how compatible it is to use, and when it is 3.0, 2.1, and 1.2 will be targeted. This lets the decision which version to use up to composer and the project that is requiring this package which to use.

This was referenced Oct 8, 2016
protected function check()
{
if (
$this->length !== false &&
Copy link
Member

Choose a reason for hiding this comment

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

Where can length be set to false? In general, since this is something coming from the outside, we should be extra careful and explicitely validate the value.

Copy link
Member Author

Choose a reason for hiding this comment

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

@jsor cheers, changed it to explicitly be an integer

@jsor
Copy link
Member

jsor commented Oct 26, 2016

I think it'd be better to replace the BufferedSink by a ReadableStream which ends the stream once $length is reached. Since the sink is used by the parsers, it looks really dangerous to me reading all the data into a buffer.

There should probably also be some kind of protection against eating too much memory, something like PHP's post_max_size. I'm not sure yet were this should be implemented. Either here or in the parsers.

@WyriHaximus WyriHaximus changed the base branch from master to 0.5 November 30, 2016 20:34
@clue clue closed this Feb 16, 2017
@clue clue changed the base branch from 0.5 to master February 16, 2017 14:46
@clue clue reopened this Feb 16, 2017
@clue clue modified the milestone: v0.8.0 Feb 16, 2017
@WyriHaximus
Copy link
Member Author

Closed through #216

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants