PEAR is archived and read-only

This mirror preserves historical PEAR package releases and metadata so existing references remain available.

Home » HTTP » HTTP_Request » Bug #1045

HTTP_Response ignores all but the last of multiple headers with equal name

Details

Submitted2004-03-21 02:17 UTC
Fromice-k at amnesty dot scene dot pl
Assignedavb
StatusClosed
PackageHTTP_Request
PHP Version5.0.0b4 (beta4)
OSFreeBSD
Roadmaps(Not assigned)

Comments

[2004-03-21 02:17 UTC] ice-k at amnesty dot scene dot pl

Description:
------------
In _check_options class HTTP_Request send OPTIONS Request
my server response like that:
---
Server: Apache/2.0.48 (Unix) DAV/2 SVN/1.0.0 Catacomb/0.9.0 PHP/5.0.0b4 mod_ssl/2.0.48 OpenSSL/0.9.6e
DAV: 1,2
DAV: version-control,checkout, checkin, report
DAV: uncheckout,version-controlled-collection
DAV: <http://apache.org/dav/propset/fs/1>
MS-Author-Via: DAV

_check_options always return false becourse class HTTPRequest could not properly fetch this sames headernames !!(names will be overwrite)

[2004-10-22 18:02 UTC] lists at cyberlot dot net

Same problem had to comment out 795-798 in Stream.php
If you look at the object info below you will see there clearly is a dav_level of 1 but its within a subarray not being seen by $this->dav_level["1"]

HTTP_WebDAV_Client_Stream Object
(
[url] => http://projects.cyberlot.net/svn/cyberss
[path] => /svn/cyberss
[position] => 0
[stat] => Array
(
)

[user] =>
[pass] =>
[dav_level] => Array
(
[<http://apache.org/dav/propset/fs/1>] => 1
)

[dav_allow] => Array
(
)

[dirfiles] =>
[dirpos] => 0
[eof] =>
[locktoken] =>
[context] => Resource id #13
)
Array
(
[/svn/cyberss/] => Array
(
[mode] => 16822
[ctime] => 1098406644
[atime] => 1098388644
[mtime] => 1098388644
)

)

[2006-09-05 13:01 UTC] giunta dot gaetano at sea-aeroportimilano dot it

I do not think the proposed patch fixes the proble THE RIGHT WAY (TM):

the spec says that only headers that have a csv format can be sent on multiple lines

this means that sending twice e.g. content-lenght is wrong

but lots of misconfigurations / bad clients 'in the wild' can lead to this situation

and using the last received content-lenght header might be a better idea than using an XX,YYY string for that (unless you want the client script to fail, so that the coder can go ask questions to the admin responsible for the server)

the only approach I see correct for this problem is a whitelist (blacklist?) of http headers

My 2 c.
Gaetano Giunta