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
