Hi, I think that I solved the underlying bug that surfaced with Esteban's problem accessing Google HTTPS using stunnel as well as Andy's problem accessing delicious.com (both were related) - for the technical details see below. The following expressions should now return true (tested with Pharo 1.2.1 on Mac OS X and Linux, Pharo Core 1.3 on Mac OS X). (ZnHttpClient new url: 'http://delicious.com'; get) includesSubString: 'Delicious' --- ; assuming stunnel is running with a config including client = yes [google] accept = 20011 connect = encrypted.google.com:443 --- (ZnHttpClient new url: 'http://127.0.0.1:20011'; get) includesSubString: 'SSL' Please let me know if your code now works as well. Thanks again, Esteban, Andy and Matt for pushing these issues ! Sven PS: please note that for now, only ZnHttpClient follows redirects, not the simpler ZnClient and the implementation of ZnHTTPSocketFacade. ==================== Summary ==================== Name: Zinc-HTTP-SvenVanCaekenberghe.150 Author: SvenVanCaekenberghe Time: 1 May 2011, 7:19:13 pm UUID: 8fe0b470-7728-454d-bc90-fa42d8330817 Ancestors: Zinc-HTTP-SvenVanCaekenberghe.149 fixing a problem where responses without an explicit content-length but with an entity where not read as they should (thanks Esteban Lorenzano & Andy Burnett for reporting this): - ZnResponse>>#entityReaderOn: now extends the super entityReader with the #allowReadingUpToEnd option - ZnEntityReader>>#entityReader now swallows entities when they are #isEmpty (making them nil) - ZnStringEntity>>#readFrom: is split between #readLimitedFrom: and #readUpToEndFrom: where the last method has extra error handling to swallow ConnectionClosed exceptions (similar to what SocketStream>>#upToEnd does) - the ZnEntity hierarchy now implements #isEmpty