back to dev

[m6w6/ext-http] / KnownIssues.txt

diff --git a/KnownIssues.txt b/KnownIssues.txt
index 62ba03294c4bc96bb1b98c6c2356ebf110add072..4c2ad80b6025a49554ce2b2c54e6b02063385c26 100644 (file)
--- a/KnownIssues.txt
+++ b/KnownIssues.txt
@@ -1,33 +1,25 @@
 Known Issues
 ============
-$Id$
-
-HttpResponse (only in PHP-5.1+):
-       HttpResponse::getHeader() does not work in Apache2 with a 
-PHP version lower than 5.1.3 (as mod_php).
 
 Windows:
        If you keep getting "SSL connect error" when trying to issue 
-requests, try another (newer) libeay32.dll/ssleay32.dll pair.
-
-Deflate/Inflate:
-       http_inflate() resp. the HttpInflateStream should be able to inflate
-any compressed data (gzip, deflate AKA zlib and raw deflate).  However,
-inflating raw deflated data causes a re-initialization of the inflate
-stream where the corresponding window bits are modified to tell libz
-to not check for zlib header bytes.  This is not preventable AFAICS.
-       http_deflate() resp. the HttpDeflateStream should be able to
-generate any compressed data (gzip, deflate AKA zlib and raw deflate);
-just use the flag for the data format you want to generate:
-HTTP_DEFLATE_TYPE_GZIP, HTTP_DEFLATE_TYPE_ZLIB or HTTP_DEFLATE_TYPE_RAW.
-       Using an encoding stream filter on a stream you read from, will
-not work as expected in a PHP version lower than 5.1.3.
+               requests, try another (newer) libeay32.dll/ssleay32.dll pair.
 
 Internals:
-       -       there's a memleak with sizeof(zval) for each thrown exception, 
-               which ends up in HttpRequestPoolExcepiont::$exceptionStack, in 
-               HttpRequestPool::__construct(); it doesn't happen with wrapped
-               exceptions in HttpRequestPool::send().
-
-       -       our http_urlencode_hash() only handles arrays and does not
-               differentiate between prefixes for numeric or string keys.
+       Inflating raw deflated data causes a re-initialization of the inflate
+               stream where the corresponding window bits are modified to tell libz
+               to not check for zlib header bytes.  This is not preventable AFAICS.
+       LFS dependant parts of libcurl are left out because of off_t,
+               respectively off64_t confusion.
+       Persistent handles and "cookiestore" request option do interfere,
+               as libcurl saves the cookies to the file on curl_easy_destroy(),
+               cookies are not saved until the CURL handle will be recycled.
+                       Thus one would either need to
+                               * run PHP with raphf.persistent_handles.limit = 0
+                               * call raphf\persistent_handles_clean() every request
+                               * call $client->flushCookies(), which is available
+                                 since libcurl v7.17.1 and does not work with the
+                                 procedural API
+       HTTP and Proxy authentication information (username/password) can not be
+               unset with NULL prior libcurl v7.19.6 and separate options for setting
+               username and password--which work--are only available since v7.19.6.