0

Pretty sure this is an IIS configuration-issue since it works in our local dev AND test environment, but not in production. Haven't been able to find the configuration issue though, hence this question.

This is the service method in question

    [WebInvoke(UriTemplate = "GetSpecificData/{type}/{id}/{categories}", Method = "POST", ResponseFormat = WebMessageFormat.Json)]
    [OperationContract]
    string GetSpecificData(string id, string type, string categories);

We are calling it with this url for example:

/Services/MapService.svc/GetSpecificData/Office/18.029788,59.332478/0

In production it immediatly results in a http status 400 and "Bad request" from server. Locally and in our test environment it works just fine.

We think the problem is related to the ID-part. if we change it to practically anything else, however small the difference, it seems to work. Here are some examples

Does not work: 18.029788,59.332478

WORKS

  • 19.029788,59.332478 works
  • 28.029788,59.332478 works
  • 18.129788,59.332478 works
  • 18.029788,59.432478 works
  • 18.029788,59.asdfasd332478
  • 18.asdf029788,59.332478

Does not work: 16.163657,60.146846

WORKS

  • 16.263657,60.146846
  • 16.363657,60.146846
  • 16.463657,60.146846
  • 16.563657,60.146846
  • 16.663657,60.146846
  • 16.163657,60.246846
  • 16.363657adsfasdfasdfasdf,60.146846asdfasdfasdfa

In our search for answers and narrowing things down these are a few things we've concluded

  • HTTP or HTTPS doesn't matter
  • No ISA or FW is causing it
  • weird characters in url (like the comma, or dot..) is not the issue
  • the length of the request is not the issue, it can be waaay longer (260 chars)

Please oh please, hope someone has ideas on what this can be. It drives me crazy not figuring it out. Apparently there's ways to solve the problem by rewriting the service to take query params or simliar but I really want to understand what causes this problem

Ivar
  • 119
  • 1
  • 1
  • 6
  • Have you tried [URL-encoding the comma](http://stackoverflow.com/questions/8828702/why-is-the-comma-url-encoded) – parapura rajkumar Aug 22 '12 at 16:32
  • An URL is limited to 255 chars. The difference between *works* and *does not work* is the lenght. Considering the root address (what comes before the `/Services`, aren't you overflowing it? – Andre Calil Aug 22 '12 at 16:35
  • @parapura: The comma isn't the problem if you look at the "works"-versions. – Ivar Aug 22 '12 at 19:01
  • @Andre Calil: that was a thought of mine too. Then I realized the url was < 100 chars in total and got dissapointed :) I decided to try it anyways and upped the maxUrlLength to something higher but of course it didn't help. – Ivar Aug 22 '12 at 19:02

1 Answers1

0

Apparently "400 Bad request" doesn't mean that IIS has denied the request to enter your application (like we thought). We managed to setup a trace on the production machine and finally found that it did enter the code and that there was a LINQ OrderBy that used a field that sometimes is null. So a simple NullReference in the end...

Ivar
  • 119
  • 1
  • 1
  • 6