2

I've set up an OData service using ASP.NET Core Web API with OData (Microsoft.AspNetCore.OData).

My unbound function has one parameter accepting a string that can be very long: http://localhost:5000/odata/MyFunction(ids='a,b,c,d,e,f').

This works fine if the length of ids doesn't get too big. However, when passing a too long string, the request fails with HTTP 400.

I've already tried this - unfortunately, it didn't work.

How do I have to configure the app so that long requests are supported both in production (Kestrel) and dev (IIS Express) mode?

mu88
  • 4,156
  • 1
  • 23
  • 47
  • How long is "long"? – mxmissile Apr 22 '20 at 14:20
  • Total length of URL: 288 signs are OK, 289 fail – mu88 Apr 22 '20 at 14:23
  • Can you try using a querystring param instead? See this Q: https://stackoverflow.com/questions/40448588 – mxmissile Apr 22 '20 at 15:23
  • Yes, this helps somehow: I had to change my parameter types because `DateTimeOffset` doesn't seem to be supported. Furthermore, I couldn't find any information about how to create an OData operation instead of function (this is the difference between `MyFunction(*)` and `MyFunction?*`, as far as I understand). So I can call it as a regular Web API, but OData clients cannot – mu88 Apr 23 '20 at 06:07

1 Answers1

3

The problem is not the length of the URL itself. Instead, it is related to OData functions, which lead to a very long URL segment. On Windows, this seems to be limited to 260 characters. So in my case, the URL segment MyFunction(ids='a,b,c,d,e,f') is simply too long.

I found two different approaches:

  1. Change a Windows Registry setting (see here). I didn't test it, but the comments in the other thread look promising.
  2. Use Parameter Aliases.

I've chosen the second approach, so now my URL looks like this: http://localhost:5000/odata/MyFunction(ids=@p1)?@p1='a,b,c,d,e,f'. The neat thing about this is that I hadn't to change anything in my OData configuration - it just works.

After a bit of testing, I reached the maximum query string length. I solved this by introducing a web.config file with the following content:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.webServer>
    <security>
      <requestFiltering>
        <requestLimits maxUrl="20100" maxQueryString="20000" />
      </requestFiltering>
    </security>
  </system.webServer>
  <system.web>
    <httpRuntime maxUrlLength="20100" maxQueryStringLength="20000" />
  </system.web>
</configuration>

The downside of the second approach is that Power BI Desktop doesn't seem to support this easily. I was not able to add a parameter alias within the simple UI when browsing an OData service. However, when creating a Power BI Parameter with the long query string, I was able to compose the OData URL with the Power BI Parameter als Parameter Alias on my own.

mu88
  • 4,156
  • 1
  • 23
  • 47
  • Another alternative is to not use a batch. Odata supports batching (and you can submit one item as batch) and then suddenly the URL is the batch endpoint and the payload is in the content ;) No URL length limit anymore. – TomTom Apr 23 '20 at 09:23
  • But how good is the support of BI tools like Power BI and Tableau for batching? I'd expect rather poor – mu88 Apr 23 '20 at 09:29
  • It is not. It is a way that is defined in the odata specs as alternative. It is not the responsibility of the specs to support tools that do ignore the specs. – TomTom Apr 23 '20 at 10:09
  • Sure, I totally agree with you. But on the other hand, writing a spec compliant OData service which cannot be used by our customers is not an option either – mu88 Apr 23 '20 at 10:13
  • 1
    Yeah, So? Do not get me wrong - I also write odata services. But at the end, whoever writes a consumer has to follow the specs, too. URL length limitations are a fact of life (and yes, you can increase them - but how do you do that on a corporate firewall that your clients may use?). This is a bad scenarios regardless how yo ulook at it – TomTom Apr 23 '20 at 10:24