Why this error happens?

BAT sends requests to the server through HTTP in the form of SOAP and GET/POST requests. Something in the middle (between report module and BAT application server) spoils these requests by changing headers, cutting off body, etc.

It may be an antivirus, a firewall, a proxy server – whatever. But something intercepts the HTTP request that comes out of report/admin module and "fixes" it. And this is the problem. IIS gets a spoiled request and answers with "400 bad request" error.

This has nothing to do with BAT at all. This is about broken communication of ANY application with the Internet Information Services.

How to See the Request?

Let us run Fiddler on the client machine – this is a free application which shows HTTP traffic. You will be able to see all HTTP requests coming out and in:

Then run report module and set up the following proxy settings on logon form:

(but please, DO NOT enter http://localhost or http://127.0.0.1 in the Server, otherwise Fiddler won't see it; use name of the server instead if you are doing all these steps on the server locally).

When you press OK, you will see this:

Each request looks like this:

POST http://vega/Service/DataPortalService.asmx HTTP/1.1

User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; MS Web Services Client Protocol 2.0.50727.5448)

Content-Type: text/xml; charset=utf-8

SOAPAction: "DataPortalRemote/Execute"

Host: vega

Cache-Control: no-store,no-cache

Pragma: no-cache

Content-Length: 3896

<?xml version="1.0" encoding="utf-8"?><soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"><soap:Body>

<Execute xmlns="DataPortalRemote"><aTicket><data>UEsDBBQAAAAIADt9WEGJp7K6/////xABAAAEAAAAR

GF0YWNgZGBg+A8EIBoEeJiARKBbUWJuanl+UbZTYnGqjkJYalFxZn6erbGemYEeEOooOJfmlJQWpdrmpZaWFCXm6C

gElCblZCZ7p1aG5Gen5tlaGFiapJglWaSZmlommyaasoLMN0IxVs+ptDgzL7W4WM8lsSQxIL+oJDEHiRmSmZy

dWgLSxhpfkpmbys4EchknM5DgBxEBQMxUc/1kHPtz55Nrc47VL0lOmDE5Q+M2l/LN4BnrD8QVlcwyetWy7G/nk

1NFD2Zu+2vWx3NO/EjrST/n00rfeUXy9LhyvR7pz+H9NTeue8XfrRt2TJCr4QYAUEsBAjMAFAAAAAgA+cwg9UTGp4Co0cmx6cND+ ==</data></aParameter></Execute></soap:Body></soap:Envelope>

The green part is a header. It contains some lines with SOMEHEADER: SOMEVALUE format. The blue part is a body. Usually it contains a valid XML (if this is a SOAP request), but also it may be empty in the case if a request is GET to FileGet.aspx.

Error "400 bad request" appears because something spoils the request. We faced with cases when users had improperly configured McAfee, Norton Internet Security, Web Washer, ISA Serer, etc., and those components intercepted the request and did some modifications. Sometimes they "fix" headers, sometimes they "cut off" the body, sometimes they just "fix a little bit" the body – depends on the application.

Server Part

First of all, we should find what comes in the server. You know already what comes out of the client (using Fiddler). Now it is time to compare with what we get on the server.

We suggest using Wireshark on the server. It is also a free application. When you run it on the server, press this buttons:

You will get a lot of messages coming in. You have to filter just those messages, which are interesting to you – HTTP requests that come from the client machine that has problem "error 400: bad request".

In this box enter the following string:

And then press "Apply". The IP address in your case should be the address of the client machine.

Now you will see this:

As you may see, the first line is a request from client machine, the second line is a response. In my case the status is "200" – that means "OK". In your case you should find the requests before a "400 bad request" response.

A useful thing will be this item in context menu:

It will show you all the stream:

Conclusion

To find out the reason why you receive "400: Bad request" you need to

1. Capture HTTP request on the client machine using Fiddler
2. Capture HTTP request on the server (at the same time) using Wireshark
3. Compare 2 requests and see what is spoiled.

You will find out that there is a difference between them. Check these:

1. Read attentively all the headers of request in Wireshark – if there is any missing one or modified one (in comparison to Fiddler's headers);
2. Read all the body of request in Wireshark – it should have same size and contents as body of Fiddler's request.

If you found a difference and see something strange, what to do next? Well, you need to find "who is guilty":

1. Temporarily unplug Norton/Kaspersky/WebWasher (depending what you have) and see if error 400 disappears.
2. Check the proxy server and set up an "exception" – to allow traffic to http://yourserver come in/out without any modifications.
3. Set up and exception in Norton/Kaspersky/Webwasher (whatever you have) to allow processes BATReport.exe and BATAdmin.exe connect by HTTP to any address.

In any case, NOTHING SHOULD INTERCEPT THE HTTP TRAFFIC COMING OUT AND IN THE BAT CLIENT APPLICATIONS. You should find what does it, and fix this component – either unplug it, or set up an exception rule to allow report/admin module successfully "pass through" by HTTP.