>
> *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
rem
I have just reviewed the current document, you can find my feedback below.
*Client: *It specifies that a client that decodes a gzipped body must
remove the corresponding header. Does it also have to remove a chunked
encoding header? It's a requirement of the HTTP specification that a client
dec
ite to any destination in an abstract way. Without this, it just doesn't
> seem possible. If you believe it is, perhaps you could demonstrate?
>
The implementation will probably involve a layer of indirection. It's
probably simpler to go with a `WritableStream` as you suggested, but
>
> Having given it quite a bit of thought, and passing this by @mecha, I
> would like to provide some feedback with regard to working with streams. As
> a disclaimer, I would like to mention that I do not make solving a specific
> problem the target of this standard; however, I do want to make
>
> Something like that is pretty stupid. It prevents having an implementation
>> that's compatible with both, 5.6 and 7. And two versions of a package can't
>> be installed side-by-side with Composer. New major versions of PSRs should
>> definitely use new package names for that reason.
>>
>>
On Friday, August 4, 2017 at 10:54:08 AM UTC+2, Adrien Crivelli wrote:
>
> I can see that Woody is feeling strongly in favor of support of PHP 5.6. I
> assume he knows what he is talking about better than myself and will trust
> him on that. Let's not waste more time debating on something that ca
On Friday, August 4, 2017 at 10:54:08 AM UTC+2, Adrien Crivelli wrote:
>
> I can see that Woody is feeling strongly in favor of support of PHP 5.6. I
> assume he knows what he is talking about better than myself and will trust
> him on that. Let's not waste more time debating on something that ca
>
> Yet, I'm really happy to discuss this issue if you think it is worthwhile,
> but we have a strong deadline. If we change the way exceptions are handled,
> we must do so before Tuesday, 17th because it is the last possible date for
> a PSR to enter (again) a review phase, so please, give me
1. Cees-Jan Kiewiet
2. Sara Golemon
3. David NĂ©grier
4. Larry Garfield
5. Michael Heap
--
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
>
> So just to get this straight: we remove the sentence (because it sounds
> weird to have it in a standard), but we agree that it's still completely
> fine if implementations have extra *optional* parameters right?
If it were completely fine, we wouldn't remove the sentence, no? Optional
pa
I guess I'm too late. Is there any reason to use the abbreviated
`getRels()` and `withRel()`, but the long form for attributes
(`getAttributes()`)? Feels inconsistent. I'd prefer `getRelation()` as well.
Regards, Niklas
On Monday, August 15, 2016 at 7:22:20 PM UTC+2, Matthew Weier O'Phinney
wr
On Tuesday, August 16, 2016 at 3:14:14 AM UTC+2, Jason Walker wrote:
>
> I disagree with removing the -Interface suffix.
>
> Not so much that I think it has to be there, but more along the lines of
> if it isn't going to be there then the FIG should select a new, perhaps
> less verbose, naming
I strongly support this. We took the same decision for
async-interop: https://github.com/async-interop/event-loop/issues/5
How do you propose to resolve this common problem?
> namespace Zend\Diactoros;
> use Psr\Http\Message\ServerRequestInterface;
> class ServerRequest implements ServerRequestIn
13 matches
Mail list logo