Update src/Httpful/Response.php

[papi83dm]

Fixed the override of a header key with multiples name, example Set-Cookie appears more than once.

[nategood]

I'm on the fence as to whether or not headers that occur more than once should be represented as an array or as a concatenated string. Regardless you are correct, we need to handle this better than just overwriting it :-).

[papi83dm]

Thanks for the reply, I found a bug on my fix, I ended up making a new
variables for the cookies.

if($key=='Set-Cookie')
{
$tmpcookie = explode(';',trim($raw_value));
$this->cookie .= $tmpcookie[0].'; ';
}

I end up doing this, and only storing the cookie portion and ignoring the
expire time and domain, etc. when using the respond, its only care about
the cookie values, not the date.

On Sat, Sep 15, 2012 at 10:56 AM, Nate Good [email protected]:

I'm on the fence as to whether or not headers that occur more than once
should be represented as an array or as a concatenated string. Regardless
you are correct, we need to handle this better than just overwriting it :-).

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/50#issuecomment-8585423.

[nategood]

I'm glad you found a solution. After digging into it, it appears, though while it is valid to have multiple headers with the same name, the HTTP spec states that such a case MUST also be able to be represented as single header with a comma separated list.

Multiple message-header fields with the same field-name may be present in a message if and only if the entire field-value for that header field is defined as a comma-separated list [i.e., #(values)]. It must be possible to combine the multiple header fields into one "field-name: field-value" pair, without changing the semantics of the message, by appending each subsequent field-value to the first, each separated by a comma. The order in which header fields with the same field-name are received is therefore significant to the interpretation of the combined field value, and thus a proxy must not change the order of these field values when a message is forwarded.

The cookie RFC outlines this this too (see 4.2.2).

Because of this, all headers that appear more than once will appears as a comma-separated list. I understand that this could be wacky for Set-Cookie header because in some cases the values contain ,. I'm just going to follow the spec here though.

[papi83dm]

Keep me posted

Sent from my iPhone

On Sep 15, 2012, at 11:19 AM, Nate Good [email protected] wrote:

I'm glad you found a solution. After digging into it, it appears, though
while it is valid to have multiple headers with the same name, the
HTTP spechttp://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.2states
that such a case MUST also be able to be represented as single
header with a comma separated list.

Multiple message-header fields with the same field-name may be present in a
message if and only if the entire field-value for that header field is
defined as a comma-separated list [i.e., #(values)]. It must be possible
to combine the multiple header fields into one "field-name: field-value"
pair, without changing the semantics of the message, by appending each
subsequent field-value to the first, each separated by a comma. The order
in which header fields with the same field-name are received is therefore
significant to the interpretation of the combined field value, and thus a
proxy must not change the order of these field values when a message is
forwarded.

The cookie RFC http://www.ietf.org/rfc/rfc2109.txt outlines this this too
(see 4.2.2).

Because of this, all headers that appear more than once will appears as a
comma-separated list. I understand that this could be wacky for Set-Cookie
header because in some cases the values contain ,. I'm just going to follow
the spec here though.

—
Reply to this email directly or view it on
GitHubhttps://github.com//pull/50#issuecomment-8585613.

[papi83dm]

The name making to the classes are wrong, I'm assuming you tested this on a
windows environment.

On Sat, Sep 15, 2012 at 11:40 AM, Jose Medina [email protected] wrote:

Keep me posted

Sent from my iPhone

On Sep 15, 2012, at 11:19 AM, Nate Good [email protected] wrote:

I'm glad you found a solution. After digging into it, it appears, though
while it is valid to have multiple headers with the same name, the HTTP
spec http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.2states that such a case MUST also be able to be represented as single
header with a comma separated list.

Multiple message-header fields with the same field-name may be present in
a message if and only if the entire field-value for that header field is
defined as a comma-separated list [i.e., #(values)]. It must be possible
to combine the multiple header fields into one "field-name: field-value"
pair, without changing the semantics of the message, by appending each
subsequent field-value to the first, each separated by a comma. The
order in which header fields with the same field-name are received is
therefore significant to the interpretation of the combined field value,
and thus a proxy must not change the order of these field values when a
message is forwarded.

The cookie RFC http://www.ietf.org/rfc/rfc2109.txt outlines this this
too (see 4.2.2).

Because of this, all headers that appear more than once will appears as a
comma-separated list. I understand that this could be wacky for Set-Cookie
header because in some cases the values contain ,. I'm just going to
follow the spec here though.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/50#issuecomment-8585613.

[nategood]

No. I usually avoid Windows when possible. Can you elaborate?

[papi83dm]

I originally had a problem when I installed, file not being found, linux
uses case sensitive and I believe on your start.php file you have them in
lower case.

On Tue, Sep 18, 2012 at 11:34 AM, Nate Good [email protected]:

No. I usually avoid Windows when possible. Can you elaborate?

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/50#issuecomment-8658969.