I think this may technically be a PSR-7 issue, not PSR-17, or perhaps it's an area that overlaps both. I ran into this issue myself when working on ApiProblem. and it took me a while to figure out that the cursor was not where I expected it to be. :-)
A SHOULD errata sounds like the right solution, I agree. What that SHOULD should be, I'm not sure yet; I largely defer to the PSR-7/17 WGs and Editors. --Larry Garfield On Saturday, December 29, 2018 10:31:17 AM CST Woody Gilk wrote: > Good report, Martijn! > > From my perspective, it would make sense that the position would be always > be set to the end of the stream, as if the stream had just been written, > mirroring the fopen(), fwrite() sequence that would normally be done. > > I'm not quite sure on the bylaws about level of recommendation, but an > errata to the following would cover this: > > Streams SHOULD have their internal pointer set to the end of the underlying > resource. > > FIG, would having this as an errata be acceptable? > -- > Woody Gilk > https://shadowhand.me > > > On Fri, Dec 28, 2018 at 6:07 PM Martijn van der Ven < > > [email protected]> wrote: > > There seems to be some disagreement on where the file position indicator > > (cursor) ends up upon the creation of a Stream instance. I have done some > > minor testing and put the results on GitHub > > <https://github.com/Zegnat/php-psr17-test-cursor>. This can lead to > > incompatibilities when doing something like: > > > > echo (new StreamFactory)->createStream('Hello!')->read(6); > > > > - createStream() seems to be the most contested. The cursor goes at > > the start or end of the string. Even more surprising (to me) is that > > Diactoros will result in a different state depending on whether you use > > its > > own factory or the tuupola one. (Again showing how compatibility may be > > an > > issue here!) > > - createStreamFromResource() seems to be agreed upon by all > > implementations: keep the cursor wherever it was at in the original > > resource. Even without specifically being defined by the PSR this makes > > a > > lot of sense to me, and I will propose adding a test for this to the > > (official) unit tests. > > - createStreamFromFile() has one of the tested implementations do its > > own thing: berlioz/http-message copies the contents of the file into a > > new > > stream and puts the cursor at the end. Every other implementations puts > > the > > cursor at the start, matching where it would be if fopen() is called on > > a > > file. > > > > Of course the (official) unit tests > > <https://github.com/http-interop/http-factory-tests> that go with the > > PSR-17 interfaces do not have tests for any of this as it isn’t covered by > > the PSR itself. > > > > The default for createStream() is a coin toss to me. I see no clear > > argument for either position. But I do think the PSR should define a > > location. This does not sound like something that can just be errata’d in, > > and defining behaviour now will lead to breaking changes in > > implementations > > > > :( Not sure what the way is to start addressing this. > > > > For *FromResource() there seem to be good reasons to just leave the cursor > > be where it is, and I believe this can be mentioned by the PSR. As all > > implementations do this already, maybe this can be an errata of some kind? > > > > For *FromFile() I don’t know what can be defined, other than saying it > > should follow what fopen() does by default. For files this will mean the > > cursor position is set to the start of the stream, I am not sure what the > > cursor does for other protocols/wrappers/schemes. > > > > Ideas? -- 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 [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/14326711.tG5BShbmUF%40vulcan. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: This is a digitally signed message part.
