[Pharo-project] Zn HTTP Clients accessing Google HTTPS using stunnel and delicious.com

Sven Van Caekenberghe sven at beta9.be
Sun May 1 14:04:21 EDT 2011


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







More information about the Pharo-dev mailing list