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
