You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As an example the logger plugin would have a list of content type authorized for logging (json / text / html / ....) and if stream not seekable, it would be decorated with the BufferedStream class
WDYT ? Is something like this considered as a BC Break ?
The text was updated successfully, but these errors were encountered:
sounds reasonable to me, to increase consistency and reduce the risk of debugging changing how the application works. i guess these will be guidelines and then we apply them to the plugins we manage? or could we code these into a trait that such plugins can use?
i would not consider it a BC break if we do not reduce functionality. if the logger or debug panel sometimes show less information with the changes, i think that would be acceptable.
Actual Behavior
Actually all plugin dealing with body check if the stream is seekable and also made arrengments when body is too long via an arbitrary value
Expected Behavior
It would be nice to base our default behavior by reading the
Content-Type
header of the request / response and use the https://github.com/php-http/message/blob/master/src/Stream/BufferedStream.php when a body is not seekableAs an example the logger plugin would have a list of content type authorized for logging (json / text / html / ....) and if stream not seekable, it would be decorated with the
BufferedStream
classWDYT ? Is something like this considered as a BC Break ?
The text was updated successfully, but these errors were encountered: