>
> *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
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
e. 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 I
prefer separate methods for that as mentioned above. It's trivial for an
implementation that s
>
> 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
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
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
>
> 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
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
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
12 matches
Mail list logo
