Hi Sven, On 27.07.13 00:57, Sven Van Caekenberghe wrote:
Be sure to tell the websocketpp guys about this issue ;-) Already did. The fact that websocketpp based apps return with 500 is even "funnier" IMHO...
A quick hack from our side would be to bypass the normal protocol of ZnHeader (specifically #normalizeHeaderKey:) and access its internal dictionary directly, using a private selector (named #headers) like this:
| request | request := ZnRequest get: 'http://foo.com/bar?x=1'. request headers headers at: 'FUNy-headER' put: 'test'. request writeToTranscript
which would go on the wire like
GET /bar?x=1 HTTP/1.1 Accept: */* User-Agent: Zinc HTTP Components 1.0 FUNy-headER: test Host: foo.com
It is not perfect, but I guess it would do. I stumbled about #normalizeHeaderKey: as well and took another route (which is IMHO nicer ... to remove once websocketpp is fixed).
ZnHeaders class>>#addWebSocketHeaders CommonHeaders addAll: #('Sec-WebSocket-Version' 'Sec-WebSocket-Key') ZnWebSocket already uses these strings with the exact same capitilization - and being in CommonHeaders bypasses #normalizeHeaderKey: for "known" headers. Still a hack but works.
Thanks for the feedback, make sure to tell me how it goes. After finding out about this everything else just works fine - Zinc is simply amazing when working with HTTP. For me it's the first framework (not only in Smalltalk) which really models HTTP in an OOP way without being too complicated. Simple things are easy - hard things possible :-)
PS: You do know about Zinc-WebSockets, I guess ? Yep - using them. I wasn't mentioning this explicitly as the headers "problem" applies to ZnClient and might thus be affecting all HTTP based stuff.
Best Regards, Udo