Error HTTP 400 - Bad Request when accessing a web site through ISA Server

  • Article

Why is it a bad request? If you haven’t seen this before, I see quiet often in some scenarios involving ISA Server and guess what: if I remove ISA Server from the picture it works just fine. Well, we all know that when you are wide open to Internet there is nobody inspecting your traffic anyway so you shall pass. Is the same thing as trying to get into your house without the key for the door, you can’t get in, but guess what, if you remove the door you can get in. Oh..so it got be the door the root cause of the problem, right? Better remove the door or look for your key?

 

In some scenarios when you receive the “400 Bad Request” is because is ISA Server is acting according to RFC 2616 and then sending the HTTP response to the client like this:

 

- Http: Response, HTTP/1.1, Status Code = 400,

    ProtocolVersion: HTTP/1.1

    StatusCode: 400, Bad request

    Reason: Bad Request ( The data is invalid. )

    Connection: Keep-Alive

    Pragma: no-cache

  Cache-Control: no-cache

  - ContentType: text/html

     MediaType: text/html

    ContentLength: 1852

    HeaderEnd: CRLF

  - payload: HttpContentType = text/html

 

Here it is a piece of the HTTP header with a type of request that can be interpreted by ISA Server as invalid:

 

HTTP HTTP:Request

...

...

Content-type: multipart/mixed

 

If the content type is multipart the HEX value might look like this:

 

49 53 41 2A 30 30 2A 20 20 20 20 20 20 20 20 20 20 2A 30 30 2A 20 20 20 20 20 20 20 20 20 20 2A 31 32 2A 36 31 34 32 37 38 36 35 35 31 20 20 20 20 20 2A 30 38 2A 36 31 31 31 33 35 35 30 30 31 20 20 20 20 20 2A 30 36 30 31 30 35 2A 30 39 35 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20

 

The value 20 in HEX means space (see https://en.wikipedia.org/wiki/ASCII for more info), which makes perfect sense in this case since the next HTTP packet just continued with a bunch of more spaces at the end, which supposedly will extend to a third packet if ISA haven’t drop that:

 

20 20 20 20 20 20 20 20 20 20 20 20 30 32 31 30 30 30 31 7E 47 45 2A 31 2A 31 37 32 31 7E 49 45 41 2A 31 2A 30 30 30 30 30 31 37 32 31 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 7E 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20

 

Going back to the RFC 2616 (section 4.2) you will see that this is not a good practice and ISA Server does what is supposed to be done, drop the packet. The best way to fix that is to contact the web site administrator (or application developer) and ask him to fix that. However since in almost of all outbound access you don’t have control of the site that your internal client is trying to access, ISA Server has a workaround to accept that. To workaround on this problem (since is not an ISA issue) you need should install ISA Server 2006 SP1 and after that make the registry changes suggested in the article below:

 

941293 Error message when you access a Web site through ISA Server 2006 or Microsoft Forefront Threat Management Gateway, Medium Business Edition: "HTTP 400 - Bad Request"

https://support.microsoft.com/default.aspx?scid=kb;EN-US;941293