X-Git-Url: https://git.m6w6.name/?p=m6w6%2Fext-http;a=blobdiff_plain;f=KnownIssues.txt;h=2453f2774c4acbb25cacdc0cc5c4a3945d3a0109;hp=d0dc6861ac3c9bd97c85c7e9af5545f0aa42380f;hb=b1ace11a9604ffcc496d32827aa66a2ba99db5ff;hpb=af89101537efd3a5439953a71dc5aef9f2b3daf0 diff --git a/KnownIssues.txt b/KnownIssues.txt index d0dc686..2453f27 100644 --- a/KnownIssues.txt +++ b/KnownIssues.txt @@ -2,19 +2,30 @@ Known Issues ============ $Id$ -HttpResponse class is only available for PHP >= 5.1 - -Not all places where files are handled check for open_basedir and/or safe_mode. - -Throttling with the FastCGI SAPI may behave unexpected, because libfcgi seems -not to practically flush its buffers when calling sapi_flush(). -See also http://bugs.php.net/bug.php?id=34429 - -If you keep getting "SSL connect error" when trying to issue requests on -Windows, try another (newer) libeay32.dll/ssleay32.dll pair. +PHP < 5.1.3: + HttpResponse::getHeader() does not work with Apache2 SAPIs. + Using an encoding stream filter on a stream you read from doesn't work. +Windows: + If you keep getting "SSL connect error" when trying to issue + requests, try another (newer) libeay32.dll/ssleay32.dll pair. Internals: - - the request bodies created in http_request_pool_attach() are not - destroyed in http_request_pool_detach(); may be a memory problem - in long running scripts + Our http_urlencode_hash() 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 safes the cookies to the file on curl_easy_destroy(), + cookies are not safed until the CURL handle will be recycled. + Thus one would either need to + * run PHP with http.persistent.handles.limit = 0 + * call http_persistent_handles_clean() every request + * call $HttpRequest->flushCookies(), which is available + since libcurl v7.17.1 and does not work with the + procedural API + Anyway, none of these options is really perfect. +