Yeah, it has stalled for a few weeks. but we are working on it again. The 
specification looks good, we are currently deciding on an upgrade path from 
HTTPlug. We have a proposal that we think will work. I've invited a few to 
have a look on it (Sara included). If this small group think it is fine I 
will publish it so every one could give their comments. 

If no major issues are found I will move the PSR to review. 

Den onsdag 14 februari 2018 kl. 13:11:46 UTC+1 skrev Barry vd. Heuvel:
> Apologies, I now see that PSR-18 is referenced in the Sunshine meetings (
>!topic/php-fig/sjASl6ltjHI )
>> PSR - 18 HTTP Client (*Abandoned*)
>>    - Tobias identified an issue and will be notifying the group to 
>>    source needed changes.
>>       - Tobias is waiting on *Sara to offer feedback*.
>>    - This PSR needs 2 implementations to move forward.
>> Status abandoned, is that supposed to be Draft? As you are discussing the 
> issue with the group. Or are you in search of a new Editor?
> Op woensdag 14 februari 2018 13:00:25 UTC+1 schreef Barry vd. Heuvel:
>> Hello Tobias,
>> Seeing as in the last two months, no new issues have arised, except for 
>> this PR discussing the formatting/necessity of a paragraph; 
>>, is it possible to 
>> move this to review? 
>> If there are no big objections and you are happy with the current 
>> document, a vote can be opened to move this to Review, right?
>> Thank you for your work so far! No intention to rush this, but it seems 
>> to stall a bit recently, while overall looks very useful :)
>> Op zaterdag 9 december 2017 14:00:18 UTC+1 schreef Niklas Keller:
>>> *Client:*
>>>> You are just referring to an example that show that if you modify the 
>>>> body you must to the same modifications on the headers. 
>>> Yes, I guess that's rather a specific question, as it should be clear to 
>>> other modifications. Should the `transfer-encoding: chunked` header be 
>>> removed by a client or not?
>>>> *Exceptions:*
>>>> By "smaller issues" we mean: Things that do not stop you form sending a 
>>>> request. If you are using the wrong HTTP version in the status line, that 
>>>> does not stop the client from sending the request. The server may be able 
>>>> to handle that anyways. So the client should not be "smart" and help you 
>>>> to 
>>>> fail early. 
>>> A wrong HTTP version isn't a small issue to me. Different HTTP versions 
>>> have a different message syntax and it's not wise just sending a wrong HTTP 
>>> version the client doesn't understand. The list of possible HTTP versions 
>>> is quite small, I think explicitly checking the version makes sense in 
>>> every client. In the worst case, sending another HTTP version the client 
>>> doesn't understand might result in a security vulnerability, because the 
>>> client interprets things the wrong way.
>>>> We do mention 1xx responses. They should be handled by the client.
>>> Yes, they're mentioned in the interface docs, but not in the 
>>> specification itself.
>>>> *RequestException*: 
>>>> Hm, I do not think so. Why would you ever be interested in a Request 
>>>> that was not sent? Im way more interested in the request that failed, 
>>>> right?
>>> I don't have an immediate use case, but I can imagine that it could be 
>>> useful if you want to find the failed request within a set of requests. 
>>> Having the original request available would allow using ===, which 
>>> explicitly isn't possible with the current interface.
>>> On the other hand, the request will usually be available at the place 
>>> the exception is caught I guess.

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 post to this group, send email to
To view this discussion on the web visit
For more options, visit

Reply via email to