X-Git-Url: https://git.m6w6.name/?p=m6w6%2Fext-http;a=blobdiff_plain;f=KnownIssues.txt;h=62ba03294c4bc96bb1b98c6c2356ebf110add072;hp=f4e945008aa2a6393f40225e73df0a4e180b1c2d;hb=e37040ebf8a470c77c7ae3498ee582ca20db259c;hpb=763dd73982474575c18acdc8db4cdc6eb6864ff3

diff --git a/KnownIssues.txt b/KnownIssues.txt
index f4e9450..62ba032 100644
--- a/KnownIssues.txt
+++ b/KnownIssues.txt
@@ -2,23 +2,32 @@ Known Issues
 ============
 $Id$
 
-HttpResponse class is only available for PHP >= 5.1
+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).
 
-Not all places where files are handled check for open_basedir and/or safe_mode.
+Windows:
+	If you keep getting "SSL connect error" when trying to issue 
+requests, try another (newer) libeay32.dll/ssleay32.dll pair.
 
-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.
-
-Inflating compressed HttpRequest responses happens twice if libcurl
-was built with zlib support.
+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.
 
 Internals:
-	-	the request bodies created in http_request_pool_attach() are not 
-		destroyed in http_request_pool_detach() but on reset; 
-		may be a memory problem in long running scripts which reuse one
-		request pool several times
+	-	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.