Simon Fell > Its just code > November 2003

Got the gzip support for PocketHTTP wrapped up, its in CVS if you're in a hurry, there'll be a new release of PocketHTTP soon, I'd like to get an eVC4 build up and running, but it doesn't look like stlport have eVC4 support yet, so that's going to be problematic. I hope those of you who celebrate thanksgiving had a good one.

Under PocketPC2000/2002 the following call for SO_SSL_PERFORM_HANDSHAKE works fine.

WSAIoctl( s, SO_SSL_PERFORM_HANDSHAKE, 0, 0, 0, 0, 0, NULL, NULL );

Under PocketPC 2003 this fails, and WSAGetLastError() returns a rather bogus -1, looking at the CE.NET 4.2 docs, it now states that we need to pass in the server name, but no where can i find how exactly we are supposed to do this.

I've tried passing both an ANSI string and a UNICODE string of the server name as the input buffer, but that continues to return exactly the same thing. How does this work on PocketPC 2003 ?

Yes that really does mean that I now have 5, count them, 5 Microsoft C++ IDE's/compilers installed and in regular use ( VC6, eVC3, eVC4, VS.NET, VS.NET 2003 ), I'm hoping Whidbey will at least allow the user to target different versions of the framework, so when that rolls along I can dump the earlier VS.NETs, the prospect of 6 IDE's and associated incompatible help systems is too much to bear, unless of course you have western digital stock!

Sigh, this is taken from the evc4 readme, so much for MSFT's security focus. Users need administrative privileges to use or install eMbedded Visual C++. Attempting to use eMbedded Visual C++ without administrative privileges results in errors.

I've been revisiting HTTP compression recently by adding support for gzip to the existing deflate support in pocketHTTP (why gzip is more popular I don't know, a deflate response is always smaller). This reminded me of one of the annoying things about this, is that there's no way to discover if the server supports a compressed request. I was thinking about a WSDL extension to indicate this, but as its a HTTP level thing I think it'd be better to stay within HTTP land, it would be nice if the server could include an Accept-Encoding header in its response, the client could then on subsequent requests to that URL encode the POST data according, but looking at the HTTP spec, this doesn't look legal. Does anyone know of any extensions in this space ? How about if the server returned an X-Accept-Encoding header, that should be enough, right ?

there's a bitwise complement operator (~) but why didn't they include a version for byte, it only works on (u)int and (u)long.

Cool, I see Richard Caetano is up and running on RESTLog.NET :)