X-Git-Url: https://git.m6w6.name/?p=m6w6%2Fext-http;a=blobdiff_plain;f=KnownIssues.txt;h=4c2ad80b6025a49554ce2b2c54e6b02063385c26;hp=77d9836c9e94ce050cfd8eaf34e843c722d587e9;hb=refs%2Fheads%2Fv2.4.x;hpb=0dd8ced9885c983b6814dbea762fc29bc2a0ffd0 diff --git a/KnownIssues.txt b/KnownIssues.txt index 77d9836..4c2ad80 100644 --- a/KnownIssues.txt +++ b/KnownIssues.txt @@ -1,31 +1,25 @@ Known Issues ============ -$Id$ -HttpResponse class is only available for PHP >= 5.1 - -HttpResponse::getHeader() does not work in Apache2 with a PHP version -lower than 5.1.3 (as mod_php). - -If you keep getting "SSL connect error" when trying to issue requests on -Windows, 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. +Windows: + If you keep getting "SSL connect error" when trying to issue + 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.