Develop Reference

Websocket behaviors path, necessary to create a new connection on every url change?

I created a Websocket server based on websocket-sharp, with two behaviors, ex:
ws://host/behavior1
ws://host/behavior2
From JavaScript, when I open a connection to the WebSocket Server, I need to specify the URL of the behavior that will accept my message. How can I call behavior2 when I connect on the url of behavior1 without having to create a new websocket connection? Is this possible?
At this point I am considering creating one behavior that will parse my message and redirect to the appropriate message handler.
Is there any reason to use multiple behaviors beside logical division? Any reason to use this logical division even if it forces to create a new connection?

How can I call behavior2 when I connect on the url of behavior1
without having to create a new websocket connection?
When you have two URLs then you will have to make two different connections to
each of the URLs. You cannot reuse the same connection to connect to different URLs.
At this point I am considering creating one behavior that will parse
my message and redirect to the appropriate message handler.
This would be the best approach to go for. You can send say json data in WebSocket frames then parse this data to identify the appropriate behavior and process accordingly. For example you can have a JSON object as follows in each of your frames:
{
"behavior":1,
"content": "your content to be processed"
}
Is there any reason to use multiple behaviors beside logical division?
Any reason to use this logical division even if it forces to create a
new connection?
You need to use different URLs only for connection specific data that are different for each client. For example an id or name. If same client need different behaviors at different times you need can define your own convention for data in WebSocket frames as mentioned above.

Programmatically distinguish between High Anonymous Proxy, Anonymous Proxy, Transparent Proxy

Suppose I have a proxy IP address, but no infos about it.
Is this possible to know from scratch which kind of proxy it is (distant webservers doesn't know I'm behind a proxy, distant webservers know I'm behind a proxy but doesn't know my IP, distant webservers know both infos)?
Is there a simple test to verify which infos are known about me when I'm navigating?
[edit]
If someone has a simple answer like "no because [etc]", he's welcomed. My first question is "is it feasable".

Lagado Proxy Text mentioned by Joshua Drake in comments works, so it is feasible. The important thing is now to learn how does it work.
Its operation is pretty simple: just be a website. So if you can afford to set up a website which will do exactly the same and will cope with all the traffic you're going to send to it, the problem is solved.
What should such a website do? Check for headers sent by client. The relevant ones are mentioned on the Lagado's page: Via, Forwarded, X-Forwarded-For and Client-ip.
The rest should be easy.
And answering your second question: see BrowserSpy.

Consuming a web service using POST instead of the going the usual WSDL route

This is how I have currently managed to consume a particular Microsoft web service. Notice that it is located on an HTTPS server and that it requires a username, a password, and a .cer file to be installed in the operating system's "root certificate authorities".
WSHttpBinding binding = new WSHttpBinding();
binding.Security.Mode = SecurityMode.TransportWithMessageCredential;
binding.Security.Message.ClientCredentialType = MessageCredentialType.UserName;
binding.Security.Message.NegotiateServiceCredential = true;
binding.Security.Message.AlgorithmSuite
= System.ServiceModel.Security.SecurityAlgorithmSuite.Default;
binding.Security.Message.EstablishSecurityContext = true;
EndpointAddress endpoint = new EndpointAddress("https://address.of.service");
//"GreatClient" was created for me automatically by running
//"svcutil.exe https://address.of.service?wsdl"
GreatClient client = new GreatClient(binding, endpoint);
//Username and password for the authentication. Notice that I have also installed
//the required .cer certificate into the system's "root certificate authorities".
client.ClientCredentials.UserName.UserName = "username";
client.ClientCredentials.UserName.Password = "password";
//Now I can start using the client as I wish.
My question is this: How can I obtain all the information necessary so that I can consume the web service with a direct POST to https://address.of.service, and how do I actually perform the POST with C#? I only want to use POST, where I can supply raw XML data using POST directly to https://address.of.service and get back the result as raw XML data. The question is, what is that raw XML data and how exactly should I send it using POST?
(The purpose of this question: The reason I ask is that I wish to consume this service using something other than C# and .NET (such as Ruby, or Cocoa on Mac OS X). I have no way of knowing how on earth to do that, since I don't have any easy-to-use "svcutil.exe" on other platforms to generate the required code for me. This is why I figured that just being able to consume the service using regular POST would allow me to more easily to consume the service on other platforms.)

What you are attempting to do sounds painful to do now and painful to maintain going forwards if anything changes in the server. It's really re-inventing the wheel.
If you haven't considered it already, I would:
(a) Research whether you can use the metadata you have for the service and use a proxy generator native to your target plaform. There aren't many platforms that don't have at least some tooling that might get you part of the way if not all of it. Perhaps repost a question targetting Ruby folk asking what frameworks exist to consume an HTTPS service given it's WSDL?
(b) Failing that, if your scenario allows it I would consider using a proxy written in C# that acts as a facade for the service which translates it into something easier to consume (for example, you might use something like ASP.NET MVC WebAPI which is flexible and can easily serve up standards compliant responses over which you can maintain total control).
I suspect one of these may prove easier and more valuable than the road you are on at the moment.

I had to go through something similar when porting .NET WCF code to other platforms. The easiest approach I found was to enable message logging on the WCF client. This can be configured to save both envelope and body and once everything is working on the .NET side of the house, you can use the message log to have "known-good" XML request/response to port to other platforms.
I found this approach to be more elegant since I didn't have to add an additional behavior to log messages, and it can be easily enabled/disabled/tweaked in the config. The Service Trace Viewer Tool that ships with Visual Studio is also handy for reviewing the log files.

I think when you say that the service should be consumed from other platforms, which do not have proxy class generation logic, you can go with REST services. This will allow you to create input as simple string concatenation instead of complex XML. Though its applicability depends on the situation.
Check this discussion : http://social.msdn.microsoft.com/Forums/en-US/wcf/thread/6907d765-7d4c-48e8-9e29-3ac5b4b9c405/
As far as the certificate is concerned, refer http://msdn.microsoft.com/en-us/library/ms733791.aspx on how to configure it.
I know this is not a very precise answer, but you will be the best person to evaluate above procedure, hence posted. Hope it helps.

What I'll do:
1- Create a small c# app that can post on this webservice (using svcutil). And modify it to show the XML send/received. To view the xml there are several ways: logging, wireshark etc. To add it directly to the small app there is another question here that give a good answer.
2- Once you know what you have to send, you can do it in c# like this:
// implement GetXmlString() to return the XML to post
string xml = GetXmlString();
// create the url
string url = new UriBuilder("http","address.of.service",80).ToString();
// create a client object
using(System.Net.WebClient client = new System.Net.WebClient()) {
// performs an HTTP POST
client.UploadString(url, xml);
}

I'm not a .NET programmer but I've had to interoperate with a few .NET services and have lots of SOAP/WSDL experience. Sounds like you've captured the XML for your service. The other problem you'll face is authentication. OOTB, .NET web services use NTLM for authentication. Open-source language support for NTLMv2 can be hit and miss (although a quick google search pulled up a few possibilities for ruby), and using NTLM auth over HTTP may be something that you have to wire together yourself. To answer a question above: where are the auth creds? If the service is using NTLM over the wire, authentication is happening at some layer below HTTP. If the service is using NTLM to authenticate HTTP, your NTLM creds are in the HTTP Authorization header. You should be able to tell with wireshark where they are. You'll also probably need a SOAPAction header; this can also be sniffed with wireshark. For the C# client, I'm sure there are docs explaining how to add headers to your request.

Append an HTTP header to all IE requests

I have a scenario which requires me to append an HTTP header to all outgoing IE-based HTTP communications on a machine. This doesn't need to work outside of IE.
I first attempted to create a simple HTTP proxy in C#, but the performance of this proxy wasn't very good, and there were issues with HTTPS communications.
My second attempt was to use FiddlerCore, which I hoped would have better performance, but was only marginally faster than what I had created myself.
Aside from writing a TCP filter driver to do this (not in my skillset), is there another option? Strictly speaking, this doesn't have to be an HTTP header. It could even be something I tack on to the user agent string.
I was thinking perhaps about creating a simple BHO, but I'm hoping there is an easier solution... one that I can write in C# perhaps.

How about just reading the user-agent string in your code and if it's IE then append the HTTP header?

Just use user agent string. It is documented here http://msdn.microsoft.com/en-us/library/ms537503(VS.85).aspx .
Per article following registry key can be used to add to the user agent string: SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\User Agent\Pre Platform\Token = Value.

Determine if Referring Url is behind a proxy

If you go to whatismyipaddress.com using a public proxy, it will report your proxy ip, but it will also (usually) report that you're using a proxy, and your originating IP as well in many cases.
How does it do this?
Similar sites like Gmail and Craigslist can tell if the computers connecting to them are proxy servers as well.
I have a site with data that is free to browse 200x/day/ip, but I'd like to protect it from harvesting by people using proxies.
Any tips or insights into how this is accomplished are appreciated.

Please check this SO thread. It explains how to do it. It is tagged for PHP but I think the idea remains same here.
**EDIT :**I am duplicating the accepted answer here for reference :
TOR does not supply any server headers
such as X_FORWARDED_FOR, so your best
bet is to use a list of all known exit
nodes. A list can be found at
https://torstat.xenobite.eu/.
For other proxies, you can look at
server headers. Possible server
headers of interest include:
HTTP_VIA
HTTP_X_FORWARDED_FOR
HTTP_FORWARDED_FOR
HTTP_X_FORWARDED
HTTP_FORWARDED
HTTP_CLIENT_IP
HTTP_FORWARDED_FOR_IP
VIA
X_FORWARDED_FOR
FORWARDED_FOR
X_FORWARDED
FORWARDED
CLIENT_IP
FORWARDED_FOR_IP
HTTP_PROXY_CONNECTION
In PHP, you can get the value of these
fields in the $_SERVER[] superglobal.