Must a PSR-7 compliant app use the MessageInterface for output

[Dracony]

I started working on a PSR-7 implementation and I MessageInterface got me thinking about it being much more overhead than needed compared to a simple "echo". What I mean is that after you have your response generated wrapping that string into a stream seems a bit of redundant. Especially considering that to provide methods like tell() and the like instead of "echo"-ing the stream would pretty much have to use output buffering which is sort of an overhead.

Matthew said tat ZF3 will use PSR-7, does it mean ZF3 will be wrapping the output in a stream like that?

[Marco Pivetta]

On 24 March 2015 at 17:57, Dracony <draco...@gmail.com> wrote:

Matthew said tat ZF3 will use PSR-7, does it mean ZF3 will be wrapping the output in a stream like that?

--

That's what following the interface is all about

Marco Pivetta

http://twitter.com/Ocramius     

http://ocramius.github.com/

[Dracony]

Well yes, I guess that was a rather stupid question on my part. But in that case I'm afraid I'll be skipping this PSR ( well the response part at least ). I wanted to have a very thin implementation  that would basically rely on thing like set_header() to print response headers, but apparently I won't be able to use set_header() as it doesn't have a feature of writing into an arbitrary stream. This means I'll end up reimplementing a slower version of an already widely used and well tested solution.

It's a huge pity the PHP 7 feature freeze happened before this PSR gets accepted. If an implementation of this PSR became part of the SPL it would be awesome and a real gamechanger, I strongly feel it will become that one day, but until then it's a tangible overhead, especially for light stuff.

[Hari K T]

I started working on a PSR-7 implementation and I MessageInterface got me thinking about it being much more overhead than needed compared to a simple "echo". What I mean is that after you have your response generated wrapping that string into a stream seems a bit of redundant. Especially considering that to provide methods like tell() and the like instead of "echo"-ing the stream would pretty much have to use output buffering which is sort of an overhead.

Did you noticed  https://github.com/phly/psr7examples . May be it will help you .

Thanks!

[Dracony]

These are nice and they do mention wrapping the php://output stream. But that really doesn't address the issue of having to handle things like headers, cookies and the like without the use of the already proven standard PHP functions instead of rolling out my own buggy ones. Event hat is not a huge deal since I'm sure in the end we'll have a very elegant and correct implementation done by someone. But I'd really like to benchmark that implementation when it comes out.

This is not an issue with a PSR itself, it's just that I feel that a feature that is definitely used all the time ( request/response handling being such ) should be as efficient as possible. And the standard functions have been awesome so far.

[Marco Pivetta]

On 24 March 2015 at 18:15, Dracony <draco...@gmail.com> wrote:

These are nice and they do mention wrapping the php://output stream. But that really doesn't address the issue of having to handle things like headers, cookies and the like without the use of the already proven standard PHP functions instead of rolling out my own buggy ones. Event hat is not a huge deal since I'm sure in the end we'll have a very elegant and correct implementation done by someone. But I'd really like to benchmark that implementation when it comes out.

This is not an issue with a PSR itself, it's just that I feel that a feature that is definitely used all the time ( request/response handling being such ) should be as efficient as possible. And the standard functions have been awesome so far.

You should play around with stuff like ReactPHP's web server and such. Providing the response as a stream allows you to delay its construction till the last possible moment, as well as a ton of other improvements if your API is not behind the PHP WEB SAPI.

[Dowling, Michael]

Dracony,

PSR-7 represents messages. It doesn’t have any bearing on how you transfer those messages over the wire. For server side applications, you are still free to use built in PHP functions like set_header(). You simply will take the message you’re given and call the appropriate functions to transfer the response.

--Michael

[Roman Tsjupa]

Well yes, but React is hardly a generic use case. Im more concerned about "regular" apps.

--
You received this message because you are subscribed to a topic in the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/php-fig/zzmpUsZoarQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CADyq6sKfCSd2uqXEMUws-eUJypm6x%2BW95Z8SQnJj42CUxJRzhw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Matthew Weier O'Phinney]

On Tue, Mar 24, 2015 at 12:57 PM, Dracony <draco...@gmail.com> wrote:
> I started working on a PSR-7 implementation and I MessageInterface got me
> thinking about it being much more overhead than needed compared to a simple
> "echo". What I mean is that after you have your response generated wrapping
> that string into a stream seems a bit of redundant. Especially considering
> that to provide methods like tell() and the like instead of "echo"-ing the
> stream would pretty much have to use output buffering which is sort of an
> overhead.

I did test a variety of methods for sending the message back. These included:

- while (! $stream->eof()) { echo $stream->read(4096); }
- echo $stream->getContents()
- echo $stream

What I found was that the last was sufficiently fast for most use
cases; unless you have very large files, it's likely what you want.

For large files, you'll want to emit chunks in order to preserve memory.

As Hari noted, I created a few example implementations that, in some
cases, make the stream aspects (eof/read/etc.) impossible to properly
use, while simultaneously optimizing for the `echo $stream` use case.
In other words, they're not 100% in the spirit of the interface. This
can and will occur; the interface is a general purpose one, and there
will be use cases it's not suited for.

I would argue the application layer should typehint on concrete
implementations of the StreamableInterface in order to switch behavior
based on whether you're sending a file/large response or not.

--
Matthew Weier O'Phinney
mweiero...@gmail.com
https://mwop.net/

[Roman Tsjupa]

Well I'm not just talking about writing speed, that I think actually shouldn't change much. I'm more concerned about handling the protocol without the use of good old functions like setcookie

--
You received this message because you are subscribed to a topic in the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/php-fig/zzmpUsZoarQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAJp_myX6uOdAH8%2BMBDuHwM1Z8vFE7g2J5G%2BoLK__2Mg-9y2UxQ%40mail.gmail.com.

[Matthew Weier O'Phinney]

On Tue, Mar 24, 2015 at 1:07 PM, Dracony <draco...@gmail.com> wrote:
> Well yes, I guess that was a rather stupid question on my part. But in that
> case I'm afraid I'll be skipping this PSR ( well the response part at least
> ). I wanted to have a very thin implementation that would basically rely on
> thing like set_header() to print response headers, but apparently I won't be
> able to use set_header() as it doesn't have a feature of writing into an
> arbitrary stream.

You're mixing up the ideas of representation with output.

The interfaces are representations.

You pull from the interface to send output.

The reason the representation exists is to allow verification of
messages (e.g., during unit testing), as well as to ensure that output
happens in the correct order (i.e., headers are sent before any
message body content). If you call set_header() after the output
buffer has started sending content, that header isn't sent; if you
aggregate all headers and content before sending the message, you
solve this problem.

PSR-7 describes the messages, but not how you send them or receive
them. That aspect is still up to the application, and the developer
coordinates that with the language. To emit the response, you'll
likely write code like this:

- https://github.com/phly/http/blob/master/src/Server.php#L165-L178

> This means I'll end up reimplementing a slower version of
> an already widely used and well tested solution.

It's not noticeably slower unless you were using functions like
readfile() or writing directly to php://output previously, and, even
then, you can optimize to make it essentially the same speed.

> It's a huge pity the PHP 7 feature freeze happened before this PSR gets
> accepted. If an implementation of this PSR became part of the SPL it would
> be awesome and a real gamechanger, I strongly feel it will become that one
> day, but until then it's a tangible overhead, especially for light stuff.

Benchmark it before you assume that it's slower, please; the
benchmarks I and others have run have not indicated this in the least.

> On Tuesday, March 24, 2015 at 6:59:23 PM UTC+1, Marco Pivetta wrote:
>>
>> On 24 March 2015 at 17:57, Dracony <draco...@gmail.com> wrote:
>>>
>>> Matthew said tat ZF3 will use PSR-7, does it mean ZF3 will be wrapping
>>> the output in a stream like that?
>>>
>>> --
>>
>>
>> That's what following the interface is all about
>>
>>
>> Marco Pivetta
>>
>> http://twitter.com/Ocramius
>>
>> http://ocramius.github.com/
>>

> --
> 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 php-fig+u...@googlegroups.com.
> To post to this group, send email to php...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/php-fig/aee07f54-db1d-4763-a022-abac4edcb5ed%40googlegroups.com.

>
> For more options, visit https://groups.google.com/d/optout.

[Roman Tsjupa]

Well yes, but the standard functions like set_header() dont work with streams, so it wont be possible to use them to create a native-ish representation. The only way I see of fixing this is dropping streams from the PSR. Since actually having streams does already restrict you to a particular implementation.

Perhaps a nice idea would be to have interfaces that just do getting and setting of headers and such. The messages would probably still have to be some sort of a stream, but maybe with much more limited interface ( just read/write instead of tell ) and the having a separate interface for a ResponseWriter that would do the whole stream thing.

This way a Response represented by such an interface could be printed by a NativeResponseWriter that utilizee native fubctions

You received this message because you are subscribed to a topic in the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/php-fig/zzmpUsZoarQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to php-fig+u...@googlegroups.com.

To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAJp_myW2UcOc2dhX4pHvgBNp3x7oN2TxJ71-B12j%3DpMwN-PDEg%40mail.gmail.com.

[Matthew Weier O'Phinney]

On Tue, Mar 24, 2015 at 1:45 PM, Roman Tsjupa <draco...@gmail.com> wrote:
> Well yes, but the standard functions like set_header() dont work with
> streams, so it wont be possible to use them to create a native-ish
> representation.

I don't understand what you mean by the above. Perhaps you can show me
some code you currently are using that you would like to see a PSR-7
implementation of? That would help me understand what you're trying to
do, and I can then hopefully explain where PSR-7 sits in relation to
it, as well as potentially provide an example of how you'd accomplish
it in PSR-7.

> https://groups.google.com/d/msgid/php-fig/CANamvv13mHuP1r026uUfx_jWbpb46W42Jq8hOEYt7fHVAdzd8w%40mail.gmail.com.

[Dracony]

No code on my hands, I was just thinking about it for now. But the general idea is that up to this point my apps would have a Response object that I would update with body (strring) some headers and cookies ( which are also headers, but I made special distinction for them for  the reason I'll state in a second). The my code would pretty much look like this:

foreach($response->getHeaders() as $key => $value) {

   header($key.': '.$value);

}

foreach($response->getCookies() as $key => $value) {

   setcookie($key, $value);

}

echo $response->getBody();

which is super simple, but up to that point all the Response data is nicely encapsulated. My gripe with PSR7 is that I'll have to handle things like proper headers (Content-Length, etc) and cookies myself

[Larry Garfield]

On 3/24/15 9:27 PM, Dracony wrote:
> No code on my hands, I was just thinking about it for now. But the
> general idea is that up to this point my apps would have a Response
> object that I would update with body (strring) some headers and cookies
> ( which are also headers, but I made special distinction for them for
> the reason I'll state in a second). The my code would pretty much look
> like this:
>
> foreach($response->getHeaders() as $key => $value) {
> header($key.': '.$value);
> }
>
> foreach($response->getCookies() as $key => $value) {
> setcookie($key, $value);
> }
>
> echo $response->getBody();
>
> which is super simple, but up to that point all the Response data is
> nicely encapsulated. My gripe with PSR7 is that I'll have to handle
> things like proper headers (Content-Length, etc) and cookies myself

Er, what would have been the alternative?

Take the code above, stick it into a method of a class, and it's now
nicely encapsulated. :-)

See for instance:

https://github.com/Crell/stacker/blob/master/src/HttpSender.php

A more robust implementation would special case stdout to use header(),
and otherwise write directly to the stream. Just like it special cases
a small body to send immediately vs looping (albeit with a tiny size,
because that's just demo code). I'm quite certain that if I spent the
time on it I could make that class extremely efficient for any arbitrary
output stream, but didn't feel it was worth it as a proof of concept.

But once that's written once, you will 99.4% of the time write:

$sender->send($response);

And go on with your life.

--Larry Garfield

[Roman Tsjupa]

The problem is that it looks like with PSR-7 I have to use an output stream wrapping around php://output . And if I do that I can't use the header9) method and setcookie

--
You received this message because you are subscribed to a topic in the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/php-fig/zzmpUsZoarQ/unsubscribe.

To unsubscribe from this group and all its topics, send an email to php-fig+unsubscribe@googlegroups.com.

To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/55122BCA.2020004%40garfieldtech.com.

[Matthew Weier O'Phinney]

On Wednesday, March 25, 2015 at 2:50:15 AM UTC-5, Dracony wrote:

The problem is that it looks like with PSR-7 I have to use an output stream wrapping around php://output . And if I do that I can't use the header9) method and setcookie

No, no, no. You don't have to wrap php://output at all, and, in fact, I'd really not recommend it. Use a php://memory or php://temp stream if you want to use an actual stream resource; alternately, I'll be writing a "String" implementation that will allow you to do things like:

    return $response->withBody(new String($template->render())); 

and similar. Wrapping php://output, while it would allow immediately flushing to the output buffer, essentially negates the ability to build the full response before sending it. Use a different stream instead, or create custom implementations that suit your needs.

 

To unsubscribe from this group and all its topics, send an email to php-fig+u...@googlegroups.com.

To post to this group, send email to php...@googlegroups.com.

[Beau Simensen]

On Wednesday, March 25, 2015 at 2:50:15 AM UTC-5, Dracony wrote:

And if I do that I can't use the header9) method and setcookie

My gut instinct tells me that your assessment is correct. Using header() and setcookie() would conflict w/ PSR-7 unless you are being very careful. Even then it is probably not advisable.

The PSR-7 response is intended to contain all of the response headers, including cookies.

[Dracony]

> No, no, no. You don't have to wrap php://output at all

Well I would have to wrap around php://output if I want to use header() and setcookie(), since they can't write to a different stream. If you build a String implementation you'll also have to handle cookies and headers in that implementation.

On Tuesday, March 24, 2015 at 6:57:18 PM UTC+1, Dracony wrote:

[Evert Pot]

On 2015-03-25 7:22 AM, Dracony wrote:
>> No, no, no. You don't have to wrap php://output at all
>
> Well I would have to wrap around php://output if I want to use header()
> and setcookie(), since they can't write to a different stream. If you
> build a String implementation you'll also have to handle cookies and
> headers in that implementation.

You don't actually write headers to a stream. All you have to do is
store them in an array, and loop through them when you are ready to send
the response back to the server.

For the sake of the discussion, perhaps you can actually share what
you're having trouble with. This may make it easier to point out what's
going wrong.

Evert

[Matthew Weier O'Phinney]

On Wed, Mar 25, 2015 at 9:22 AM, Dracony <draco...@gmail.com> wrote:
>> No, no, no. You don't have to wrap php://output at all
>
> Well I would have to wrap around php://output if I want to use header() and
> setcookie(), since they can't write to a different stream.

Streams are separate from headers. Completely.

You will do the following to send a response:

header(sprintf(
'HTTP/%s %d %s',
$response->getProtocolVersion,
$response->getStatusCode,
$response->getReasonPhrase()
));

// process headers
foreach ($response->getHeaders() as $headerName => $values) {
if (strtolower($headerName) == 'set-cookie') {
continue;
}
header(sprintf('%s: %s', $headerName, implode(', ', $values)));
}

// send cookies
if ($response->hasHeader('set-cookie')) {
foreach ($response->getHeaderLines('set-cookie') as $value) {
// call setcookie() with values
}
}

echo $response->getBody();

My point is: you *will* still use the native PHP functions, but you'll
do so when you're ready to emit the response. At that time, you start
sending data to the output buffer, and no sooner.

> If you build a
> String implementation you'll also have to handle cookies and headers in that
> implementation.

No — the stream is only for the message BODY. You handle cookies and
headers (and cookies ARE headers) in the message itself.

> On Tuesday, March 24, 2015 at 6:57:18 PM UTC+1, Dracony wrote:
>>
>> I started working on a PSR-7 implementation and I MessageInterface got me
>> thinking about it being much more overhead than needed compared to a simple
>> "echo". What I mean is that after you have your response generated wrapping
>> that string into a stream seems a bit of redundant. Especially considering
>> that to provide methods like tell() and the like instead of "echo"-ing the
>> stream would pretty much have to use output buffering which is sort of an
>> overhead.
>>
>> Matthew said tat ZF3 will use PSR-7, does it mean ZF3 will be wrapping the
>> output in a stream like that?
>

> --
> 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 php-fig+u...@googlegroups.com.
> To post to this group, send email to php...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/php-fig/700763fa-e151-4e09-8c6e-f985c12a950a%40googlegroups.com.

>
> For more options, visit https://groups.google.com/d/optout.

[Dracony]

in your example the cookies first have to be represetned as headers in the Response, then during output you parse 'set-cookie' headers and call setcookie(). Doesn't that look like overhead? There would have to exist a service that converts cookie data into set-cookie headers for the Response, and then something will have to decode it back from headers into setcookie() parameters. Which is kind of sad =\

Maybe then it's a good idea to add getters/setters for cookies to the Response class? Would definitely reduce redundant work of parsing them back and forth.

Another question I have is about default headers that the webserver usaully add (like Content-Length). They usually are not set by the application itself, but without them the Response representation is not complete, since it makes the assumption that some external thng will calculate content length andd add it as a header. How are those to be handled ?

[Hari K T]

Hi Dracony, 

Please implement and point what you are telling 

You can refer implementations like 

https://github.com/phly/http

https://github.com/guzzle/psr7

https://github.com/slimphp/Slim/tree/develop

and more .

The headers and setcookie is not a new concept. 

You can see in Aura.Web how the response is created https://github.com/auraphp/Aura.Web/blob/develop-2/src/Response.php and later send https://github.com/auraphp/Aura.Web/blob/develop-2/src/ResponseSender.php

If you feel we all are talking different things please show your implementation.

Happy to see the issue.

Hari K T

You can ring me : +91 9388 75 8821

http://harikt.com , https://github.com/harikt , http://www.linkedin.com/in/harikt , http://www.xing.com/profile/Hari_KT

Skype  : kthari85

Twitter : harikt

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/39773cdb-d232-42ec-99cb-8493ec5de118%40googlegroups.com.

[Larry Garfield]

On 3/25/15 10:21 AM, Dracony wrote:
> in your example the cookies first have to be represetned as headers in
> the Response, then during output you parse 'set-cookie' headers and call
> setcookie(). Doesn't that look like overhead? There would have to exist
> a service that converts cookie data into set-cookie headers for the
> Response, and then something will have to decode it back from headers
> into setcookie() parameters. Which is kind of sad =\
>
> Maybe then it's a good idea to add getters/setters for cookies to the
> Response class? Would definitely reduce redundant work of parsing them
> back and forth.
>
> Another question I have is about default headers that the webserver
> usaully add (like Content-Length). They usually are not set by the
> application itself, but without them the Response representation is not
> complete, since it makes the assumption that some external thng will
> calculate content length andd add it as a header. How are those to be
> handled ?

Please, if a thread is bottom-posting, stick to bottom-posting. Be
consistent.

Things like Content-Length et al would be handled by whatever the
"sender" service is. You could write any number of such services, all
working on the same interface. That's the point. :-)

I think there's a disconnect here in terms of how the Response object is
expected to be used. PSR-7's objects do, legitimately, less than the
Symfony Response object does, for instance. The Symfony Response object
has code in it that will, for instance, normalize cache headers (since
there's like 3 different ways to do caching, and about 15 combinations
that don't make logical sense), determine content-length if it is able
to (it's not always possible, but it does if it can), and so forth.

PSR-7's Response object does none of that; that doesn't mean code that
does so isn't important; it's very important, as you've pointed out. It
just doesn't belong in the Response object itself. SRP and all that. :-)

Basically, if you take the Symfony Response::prepare() and
Response::send() methods out and put them in their own service objects
you end up in the same place. All of the same capabilities are there,
and just as important for a full application, but they're not part of
the message itself. But by separating out the message itself (SRP FTW!)
you can write whatever prepare() and send() implementations you want.

Some of them will use header() and setcookie(). Some will write strings
to a stream. Whatever. SRP for the win. :-)

--Larry Garfield

[Roman Tsjupa]

Some of them will use header() and setcookie()

Using setcookie() will require first formatting cookies as headers ( to store in Response) , then parsing them back to params and posting through setcookie().

In that case I strongly feel that Cookie getters/setters should be added to both Request and Response.

 Since you already established that neither Request nor Response represent the actual HTTP request/response fully there is no reason to limit ourselves to "not represent cookies as cookies are headers". If cookies are added to the interface it will be possible to use the set_cookie() method to output them, without having to rely on something to parse cookies into headers programmatically.

Furthemore I strongly feel that cookies are such an integral part of day-to-day usage of HTTP and are used in pretty much every framework, that it is wasteful not to include them ina standard. Middleware developers would then be able to set and read cookies without having to rely on a custom non standardized cookie parser. I mean what is the point of having a generic HTTP interface intended for interpolability if a huge part of how it's used (cookies) remains unstandardized and will have to rely on each indivdual representation.

--

You received this message because you are subscribed to a topic in the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/php-fig/zzmpUsZoarQ/unsubscribe.

To unsubscribe from this group and all its topics, send an email to php-fig+unsubscribe@googlegroups.com.

To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/5512D6CE.40207%40garfieldtech.com.

[Beau Simensen]

On Wednesday, March 25, 2015 at 10:51:11 AM UTC-5, Dracony wrote:

Some of them will use header() and setcookie()

I mean what is the point of having a generic HTTP interface intended for interpolability if a huge part of how it's used (cookies) remains unstandardized and will have to rely on each indivdual representation.

It is already going to be expected that frameworks implement PSR-7 (or use a framework agnostic implementation). There is not a lot of extra work to do to create cookie management services/utilities as well (or use a framework agnostic cookie service/utility implementation).

[Roman Tsjupa]

Yes, and I really believe that those have to be a part of the same PSR in some way

--

You received this message because you are subscribed to a topic in the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/php-fig/zzmpUsZoarQ/unsubscribe.

To unsubscribe from this group and all its topics, send an email to php-fig+u...@googlegroups.com.

To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/ee3106c9-a3bd-4345-bb2a-2e92913fd17f%40googlegroups.com.

[Jeremy Lindblom]

> "Furthermore I strongly feel that cookies are such an integral part of day-to-day usage of HTTP..."

I completely disagree with this statement. You are looking at HTTP from the perspective of only the server (PHP application). I've worked with probably close to 50 web services during the past 5 years, and never once have I needed cookies to do that. PHP plays the role of an HTTP client too.

When it comes down to it, cookies are are just headers. When you are sending a request (with file_get_contents, sockets, or cURL), you don't use setcookie(), so modeling cookies for the purposes of calling setcookie() is not a good idea. Also, there are many other headers that can be as complicated as cookie headers, but we are not modeling them as part of this PSR either.

To unsubscribe from this group and all its topics, send an email to php-fig+u...@googlegroups.com.

To post to this group, send email to php...@googlegroups.com.

[Crypto Compress]

Am 25.03.2015 um 17:17 schrieb Jeremy Lindblom:

When it comes down to it, cookies are are just headers.

Quote: "...handle "Set-Cookie" as a special case while processing header fields."
http://tools.ietf.org/html/rfc7230#section-3.2.2

[Dracony]

Well we have already concluded that the PSR doesn't model the Response entirely and requires the use of some other service that will actually do the conversion from the representation to the actual response adding the required headers. I see no reason in that case that this internal Response representation can't contain cookie information.

Also you have to think from a practical point of view too. Using setcookie() is a very elegant and weel tested approach, so if the PSR in some way restricts the use of it ( and it does ) it needs to adapt

[Stefano Torresi]

Hello Roman,

What you're talking about has been discussed before, and it has been deemed outside the scope of the proposal.

(https://github.com/php-fig/fig-standards/blob/master/proposed/http-message-meta.md#what-about-special-header-values)

The proposal is about messages, the point being to use the same messages across different frameworks.

It is not "incomplete" in any way, you are talking about implementation details that are not described by the specs the proposal refers to.

(https://github.com/php-fig/fig-standards/blob/master/proposed/http-message-meta.md#42-non-goals)

Also, again, proposing structural changes during the vote is not going to gain much traction.

Regards.

[Dracony]

Anyway, it's really to late for me to start arguing the interfaces. Though I'm not exactly 100% ok with those after your clarifications I guess they are manegable enough to base next version of PHPixie on, so thanks for that =)

I really would like to see those Cookie handling methods added. I still have no idea how to handle those. I could either add them to my implementation, but then I would sort of break the interface because after setting a cookie getHeader('Set-Cookie') would not tell you it exists (as I don't want to parse cookies into headers myself). Or I could pass a "cookie jar" along the Request back and forth, but that just seems really redundant.

Is there any recommended way for cookie handling ?

[Matthew Weier O'Phinney]

On Thu, Mar 26, 2015 at 5:51 AM, Dracony <draco...@gmail.com> wrote:
> Anyway, it's really to late for me to start arguing the interfaces. Though
> I'm not exactly 100% ok with those after your clarifications I guess they
> are manegable enough to base next version of PHPixie on, so thanks for that
> =)
>
> I really would like to see those Cookie handling methods added. I still have
> no idea how to handle those. I could either add them to my implementation,
> but then I would sort of break the interface because after setting a cookie
> getHeader('Set-Cookie') would not tell you it exists (as I don't want to
> parse cookies into headers myself). Or I could pass a "cookie jar" along the
> Request back and forth, but that just seems really redundant.
>
> Is there any recommended way for cookie handling ?

I'm going to work on a PoC with Beau soon (TM) to demonstrate how you
might create your Set-Cookie headers. My idea is something along the
lines of:

$response->withAddedHeader('Set-Cookie', new Cookie(...));

where Cookie would be a concrete class that would take your data, and,
via __toString(), create the serialization for it.

By doing this, you can send the cookies back to the client as normal
headers, requiring no special handling in the response emitter.

One of us will post to the list when we have something for you to look at.

> On Wednesday, March 25, 2015 at 6:00:11 PM UTC+1, Stefano Torresi wrote:
>>
>> Hello Roman,
>>
>> What you're talking about has been discussed before, and it has been
>> deemed outside the scope of the proposal.
>>
>> (https://github.com/php-fig/fig-standards/blob/master/proposed/http-message-meta.md#what-about-special-header-values)
>>
>> The proposal is about messages, the point being to use the same messages
>> across different frameworks.
>>
>> It is not "incomplete" in any way, you are talking about implementation
>> details that are not described by the specs the proposal refers to.
>>
>> (https://github.com/php-fig/fig-standards/blob/master/proposed/http-message-meta.md#42-non-goals)
>>
>> Also, again, proposing structural changes during the vote is not going to
>> gain much traction.
>>
>> Regards.
>>
>>

> --
> 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 php-fig+u...@googlegroups.com.
> To post to this group, send email to php...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/php-fig/2fbef95d-0320-4195-88c2-98b7a0b89862%40googlegroups.com.

>
> For more options, visit https://groups.google.com/d/optout.

[Roman Tsjupa]

Well that would still be a problem:
Setting the same cookie multiple times would result in multiple set-cookie headers. And again you would rely on parsing cookie into heqder yourself instead of using setcookie

You received this message because you are subscribed to a topic in the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/php-fig/zzmpUsZoarQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to php-fig+u...@googlegroups.com.

To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAJp_myW94KSTgiXkv0g6LXsNx0k_1BWr4UuH-P2%2BxHNvfr2DLA%40mail.gmail.com.

[Larry Garfield]

On 3/26/15 8:36 AM, Roman Tsjupa wrote:
> Well that would still be a problem:
> Setting the same cookie multiple times would result in multiple
> set-cookie headers. And again you would rely on parsing cookie into
> heqder yourself instead of using setcookie

Please.
Stop.
Top.
Posting.

Follow the thread.

(ahem)

Honestly I think this question is being over-emphasized. I honestly do
not recall the last time I even used a cookie that wasn't the session
cookie, which is a separate matter. Everything else has been the
session or localStorage.

--Larry Garfield

[Dracony]

You really can't say that cookies are obsolete. There are a lot of usecases for cookies over session.

But since we touched on the subject of sessions. Is the Response class supposed to "know" about the session cookie, if the session has been started with session_start() separately? Or does the PSR imply that we have to override the default session handler to set cookies via the Response headers instead ?