> > I don't see what the value of this is. The reasons stated: > > > server limitations (max opened files) > > Often streams are php://memory (though it depends on PSR-7 implementation) > and therefore not subject to max opened files limit. >
Often is not all, IMHO, the streams, as defined by the PSR-7 doesn't have any usage limitations, it to read any resource. Seriously, I really seen that bug to a previous employer. It's easy to avoid it, then why not? > > performances in case of unused streams > > Memory streams, and even temporary file streams, contribute approximately > 0% overhead to a typical request load. > Memory is a point, but open a resource has also a cost in time. Avoid them both if possible, even if it's a few. > > > ability to get a stream of broken uploaded file > > What value does this have? If it's broken, it probably should not be > inspected for security reasons. > If you look in the PSR-17, it requires a stream as first parameter, send with the error code. Then if I don't interpolate too much, the error code must be checked, if it always equals to UPLOAD_ERR_OK to create a stream, that parameter is fully useless. Le mercredi 31 octobre 2018 17:59:31 UTC+1, Woody Gilk a écrit : > > I don't see what the value of this is. The reasons stated: > > > server limitations (max opened files) > > Often streams are php://memory (though it depends on PSR-7 implementation) > and therefore not subject to max opened files limit. > > > performances in case of unused streams > > Memory streams, and even temporary file streams, contribute approximately > 0% overhead to a typical request load. > > > ability to get a stream of broken uploaded file > > What value does this have? If it's broken, it probably should not be > inspected for security reasons. > > The StreamInterface is the one interface about PSR-7 that I don't care > for, but I don't see what value this change would have. > -- > Woody Gilk > https://shadowhand.me > > > On Wed, Oct 31, 2018 at 5:01 AM Lcfvs <michael...@gmail.com <javascript:>> > wrote: > >> Hi all, >> >> I just sent a proposal to add an interface to describe a late stream, >> which doesn't requires an already opened resource. >> >> For the proposal, see https://github.com/php-fig/http-message/pull/82 >> >> As said by Jean85: >> >> This is a completely non-trivial change to the spec, and also not an >>> errata. I would say that you should push for this change opening a >>> discussion on the PHP-FIG mailing list... >>> >> >> ... then I'm here. :D >> >> My motivation is about the >> >> - server limitations (max opened files) >> - performances in case of unused streams >> - the ability to get a stream of broken uploaded file >> - ... >> >> Indeed, it isn't an errata, I made it to avoid any breaking changes, it's >> why a new interface. >> >> What do you think about it? >> >> -- >> You received this message because you are subscribed to the Google Groups >> "PHP Framework Interoperability Group" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to php-fig+u...@googlegroups.com <javascript:>. >> To post to this group, send email to php...@googlegroups.com >> <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/php-fig/d91f9110-92d5-4721-8c9c-fcf0a1ada7ed%40googlegroups.com >> >> <https://groups.google.com/d/msgid/php-fig/d91f9110-92d5-4721-8c9c-fcf0a1ada7ed%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > -- You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+unsubscr...@googlegroups.com. To post to this group, send email to php-fig@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/538e1862-3a8e-4b7c-81f8-1bc999f2fb69%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
