We Keep Coding

WCF Content-Length mismatch when using IIS Compression

I have an issue where if I enable dynamic content compression in IIS 7.5, I get a different content length. I know this could happen since the data is being compressed but the problem is it is actually bigger.
Before
After
I know there are related posts like this one but the solutions are often modules modifying the content-length. In this example, I ruled that out by using a simple demo WCF app but I still get an incorrect content length. IF you think I missed the correct question / answer, just let me know.
WCF service returns incorrect Content-Length when using gzip encoding
Here is the solution of the demo wcf I am using. https://github.com/janmchan/WCFDemo.git

As it turns out, there was nothing wrong with the response. Using fiddler, I could see the saw response as the compressed version and it seems that the length corresponds to the length of those characters. So our conclusion is that the end system receiving this does not know how to handle the compressed response. I'll keep this answer open for debate until we have confirmed that this is the case.

How to compress a message using c# and decompress it using javascript?

I have a WCF Service and I want to send a message with the least characters possible.
Are there any compression methods to do this?
I want to compress it in C# and decompress it using javascript.

MTOM.
Or you could implement a custom message encoder and decoder, where you pass the data through a (de)compression engine. This implies you have control over both ends (client and service).
Unfortunately I don't know the answer to your updated question. You'd have to find some libraries that implement the same compression algorithm in both C# and Javascript. I've never done anything like that so I wouldn't know which libraries to use. You could try to manually implement something like LZW or DEFLATE, but that'll be the hard way and error-prone.

For that, you might implement one of the compression techniques explained here.

Fastest way to code up hitting a URL

I need to login to a site, then hit a certain URL about a thousand times (with different params, of course).
The URL is something this:
http://www.foo.com/bar.asp?id=x ' where x is the ID
Of course if I simply hit the URL without being logged, it will fail.
I am not very familiar with this type of work, but I would imagine that whatever the method I choose, it would have to support cookies.
I was thinking that I could create a winform app with a browser control and somehow drive it, but that seems like a massive overkill.
Is there a better way?

If you are determined to do it in your code itself then i dont think any thing is stopping you from doing that.
HttpRequest and HttpResponse classes has pretty much everything you need to do that.
Moreover if you are concerned about cookies then you could always store received cookies in a database or file and send them with every subsequent request.
If you want to know the structure of the Http Request like a GET request then look here.
Also you can make your request look like a Request from browser by specifying the Proper Request Headers...(However it doesn't work every time)
And all this can be done even in a console app

You may want to look into WCAT if you are mainly interested in how your server performs under load.

Using Python or PHP, you can use the libcURL library, I believe they both have bindings for these languages. If not, just use the urllib2 module (for Python).

Sending a binary stream through SOAP

I have a "simple" task. I have an existing project with a web service written in C# which has a method that will send a huge XML file to the client. (This is a backup file of data stored on the server that needs to be sent somewhere else.) This service also had some additional authentication/authorization set up.
And I have an existing Delphi 2007 application for WIN32 which calls the web service to extract the XML data for further processing. It's a legacy system that runs without a .NET installation.
Only problem: the XML file is huge (at least 5 MB) and needs to be sent as a whole. Due to system requirements I cannot just split this up into multiple parts. And I'm not allowed to make major changes to either the C# or the Delphi code. (I can only change the method call on both client and server.) And I'm not allowed to spend more than 8 (work) hours to come up with a better solution or else things will just stay unchanged.
The modification I want to add is to compress the XML data (which reduces it to about 100 KB) and then send it to the client as a binary stream. The Delphi code should then accept this incoming stream and de compress the XML data again. Now, with a minimum of changes to the existing code, how should this be done?
(And yes, I wrote the original client and server in the past and it was never meant to send that much data at once. Unfortunately, the developer who took it over from me had other ideas, made several dumb changes, did more damage and left the company before my steel-tipped boot could connect to his behind so now I need to fix a few things. Fixing this web service has a very low priority compared to the other damage that needs to be restored.)
The server code is based on legacy ASMX stuff, the client code is the result of the Delphi SOAP import with some additional modifications.
The XML is a daily update for the 3000+ users which happens to be huge in it's current design. We're working on this but that takes time. There are more important items that need to be fixed first, but as I said, there's a small amount of time available to fix this problem quickly.

This sounds like a good candidate for an HttpHandler
My good links are on my work computer (I'll add them when I get to work), but you can look to see if it will be a good fit.
-- edit --
Here are the links...
http://www.ddj.com/windows/184416694
http://visualstudiomagazine.com/articles/2006/08/01/create-dedicated-service-handlers.aspx?sc_lang=en&sc_mode=edit

What is the problem with a 5MB file in a soap message? I have written a document server that runs over soap and this server has no problem with large files.
If the size is a problem for you I would just compress and decompress the xml data. This can easily be done with one of the many (free) available components for compression of a TStream descendant.

If you get that kind of compression, merely convert each byte to its hex equivalent, which will only double the size, and send this. Then do the opposite on the other end. Or am I missing something?

I would agree with Brad Bruce, HttpHandler would be fast, and using GZIP or Deflate Compression with I might be wrong... browsers support natively. you can get easy great compression on text based data for cheap cpu time.
System.IO.Compression.GZipStream GZipStream = new System.IO.Compression.GZipStream("Your XML Doc Stream",System.IO.Compression.CompressionMode.Compress)

Is there a way to use .NET's built-in HTTP classes to parse "raw" TCP streams as HTTP from memory?

I am wondering if there is a straightforward way to use .NET's built in HTTP support to parse arbitrary bytes into nice HTTP requests and responses. For example, I would like to be able to pass in a byte array containing "HTTP/200 OK\r\nContent-Type:...." etc and get out some structure representing the status code, and decoded content.

I'm afraid there is not built-in support for this that you can access. This logic is embedded in internals of the HttpWebRequest-related classes of the .NET Framework.
I think the closest you can get is hosting your own web server through the System.Web.Hosting APIs, but this sounds too heavyweight for what you are describing.