Added note about async non-goal

[Nyholm]

This will fix #29

[kelunik]

should define neither promises nor an async-compatible version of PSR-7

[Nyholm]

Can you tell me why PSR-7 is not async?

[kelunik]

For example, because getContents() requires blocking, as does __toString().

[Nyholm]

That is an implementation detail. ;)

[kelunik]

No, it's not. Blocking is an absolute no-go in fully async apps.

[Nyholm]

Nowhere in the PSR-7 specification does it say that getContents has to use __toString. (In fact getContents and __toString has different behaviours. ) Nor does it say that it has to be blocking.

Im saying that you can implement PSR-7 with non-blocking. It is not a limitation in the interface but in the implementations.

[kelunik]

Of course it doesn't say it has to be blocking, as that's the default for any IO operation in PHP. It has to be blocking, because the interface requires an immediate return on a call to these methods.

Im saying that you can implement PSR-7 with non-blocking.

Could you try to elaborate how that should be possible? See what React did.

[clue]

I agree with @Nyholm here, the text LGTM and the discussion whether PSR-7 can be used in an async context is both an implementation detail and out of scope here 👍

(@kelunik IMO the last link adds little value here and its motivation is better described in the documentation (https://github.com/reactphp/http#request), rather than the code. As an alternative, PSR-7 does not prevent you from buffering the whole message in memory, in which case all accessors can be used perfectly fine even in an async program 👍)

[kelunik]

@clue It doesn't really matter as an async client is out of scope in any way, regardless of the wording here.

I completely understand the motivation behind that, but it doesn't really matter either. If it could be implemented sanely, I'm pretty sure you guys would have done that. It doesn't prevent buffering, of course not, but we both know that it doesn't fit for all bodies and is the exact reason why the request body isn't represented as a string, but a stream.

[sagikazarmark]

I agree with @Nyholm although I think we could improve this section a bit.

Here are some thoughts:

Asynchronous HTTP clients are often implemented using Promises. While a promise interface could be part of this PSR, that could delay the release of this PSR for years. Also, there is a group already working on a separate PSR for promises which could be used in a future Async HTTP client PSR.

For these reasons we decided to ... blahblah

@Nyholm can you please play with this section a bit more? See what comes out of it.

[kelunik]

A promise interface should definitely not be part of an HTTP client PSR.

[dbu]

i added one suggestion to add a bit of the discussion we had on a separate interface for async requests. if we are happy with that lets add it and merge?

[dbu]

lets maybe formulate this more neutral "would delay the HTTP client PSR." and then add "A separate interface for asynchronous requests can be defined in a separate PSR once the promise PSR is accepted. The method signature for asynchronous requests has to be different."