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)

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 ) )

the HTTP_Response::_processHeader() method in HTTP/Request.php does not take RFC 2616 Sec. 4.2 into account: 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. Instead of concatenating multiple header values for the same header field name the current code just overwrites older values proposed patch: diff -u -r1.37 Request.php --- Request.php 19 May 2004 10:17:10 -0000 1.37 +++ Request.php 9 Jan 2005 23:24:45 -0000 @@ -982,8 +982,16 @@ $headervalue = ltrim($headervalue); if ('set-cookie' != $headername_i) { - $this->_headers[$headername] = $headervalue; - $this->_headers[$headername_i] = $headervalue; + if (isset($this->_headers[$headername])) { + $this->_headers[$headername] .= ", " . $headervalue; + } else { + $this->_headers[$headername] = $headervalue; + } + if (isset($this->_headers[$headername_i])) { + $this->_headers[$headername_i].= ", " . $headervalue; + } else { + $this->_headers[$headername_i] = $headervalue; + } } else { $this->_parseCookie($headervalue); } I'd also like to comment that storing the case sensitive version of the header name doesn't make sense at all as header names are defined to be case insensitive anyway. IMHO only the lowercase version should be used to store in the headers array, at the same time getResponseHeader() should always lowercase its argument Allowing non-standard case sensitivity just doesn't make sense here IMHO, i'd even say it is a BAD THING(tm)

Fixed in CVS. Also only the lowercased version of response header is now kept, both request and response headers are treated case insensitively.

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