HTTP 403 Errors on Large Payloads into Azure App Services

Over the last few years, I’ve come to rely on Azure App Services very heavily as a host for my APIs. In my most recent project, we created an API layer that accepted some fairly large payloads. By doing such I learned a couple of things about App Services:

1. App Services are a great alternative to on-premise solutions using IIS and really delivers on the PaaS promise of removing the worries of having to manage a web server.
2. You still have to be at least a little concerned (or at least aware) of the web server.

Obviously this second point seems counter-intuitive to the general value of PaaS solutions expressed in the first point. But believe-it-or-not, buried under all the Azure Platform software and hardware we don’t have to concern ourselves with, lies some of our old familiar friends from the on-prem world. In this case, it is Internet Information Server (IIS) that provides much of the underlying capabilities provided by App Services.

We came across this by creating an API layer that accepted some fairly large payloads in the POSTs. This issue was somewhat difficult to debug at first because the vast majority of the calls into the service worked as expected. And further, it was an HTTP 403 error, implying some kind of access issue. We noticed after some time that it was only the larger requests that were failing. We found out, via Microsoft support, that our issue was due to size throttling that is implemented in IIS–which we never would have guessed as we were using App Services and not IIS and wouldn’t have considered this limitation.

The solution was fairly simple: we had to inform the underlying IIS instance to continue processing even after the threshold is hit. This is done by passing the value “100-Continue” in the Expect header on each request.

But that presented another problem: we couldn’t force all of our API clients to pass a new header for existing (and previously working) interfaces.

Fortunately, we were already using API Management and had a very easy to implement solution. We just needed a policy that attached the appropriate header to every request so the backend (our API on App Services) would work correctly. We added the following inbound policy to “All operations”:

<policies>
<inbound>
<base />
<set-header name="Expect" exists-action="append">
<value>100-continue</value>
</set-header>
</inbound>
... etc.
</policies>

After all that, things continued to work as expected!

Integrations in Azure and My BizTalk Hangover

If you’ve dropped in on this site occasionally (and my WordPress account numbers suggest that once a blue moon ago a few people have), you may have noticed that I haven’t written an article for Talented Monkeys in over 5 years. And to be frank, it was pretty sporadic for the 2-3 years prior to that as well.

So what happened? Well… this blog was primarily about BizTalk and truth be told-and even though Microsoft won’t admit it-it just doesn’t look like there’s that much interest in the product anymore. Myself, I’ve been currently focusing on Azure, particularly PaaS solutions within the integration space. To that end, you might hear from me a bit more often as I learn stuff that others probably already know, but post it here anyway for my own edification.

As always, thanks for your continued support.

Conditional Port Deployment Using the Deployment Framework for BizTalk (BTDF)

Using the Deployment Framework for BizTalk  makes the normally painful task of performing a BizTalk deployment a lot easier. If you don’t know about it, I’d highly recommend taking a look into it. Once you get it going, you’ll find there’s no better way to do a BTS deployment.

Oftentimes while doing BizTalk work, I like to create “test ports” to help me unit test my BizTalk code or configuration. These are usually file-drop locations that I don’t want included in my regular deployment. I’ve found it to be somewhat painful a process to continually have to either add or remove these test locations, so I like to use the Deployment Framework’s capability to use XML Preprocess to selectively deploy a port.

Here’s how:

First, you’ll need to make sure the value of the RequireXmlPreprocessDirectives is set to “True” in the deployment project file. Then, in the PortBindingsMaster file, you simply comment out the port you want to be conditional and wrap it in a preprocessor directive like such:

<!-- ifdef ${_xml_preprocess} -->    
<!-- <ReceivePort Name="TEST" IsTwoWay="false" BindingOption="0">
      <Description xsi:nil="true" />
      <ReceiveLocations>
      <ReceiveLocation Name="TEST_FILE">
          <Description xsi:nil="true" />
          <Address>${someVariable}\*.xml</Address>
          …
      </ReceivePort> -->
<!-- endif -->

When you need to turn it off, you simply change the value of RequireXmlPreprocessDirectives to “False” and BTDF will treat your port definition as it would any other commented out code-it’ll ignore it.

One caveat to this approach, though, is that you’ll need to wrap ALL other variable-based definitions in the PortBindingsMaster with preprocessor directives as such:

<!-- ifdef ${_xml_preprocess} -->
<!-- <Address>mssql://${dbServerName}//${dbName}?</Address>-->
<!-- else -->
    <Address>mssql://${dbServerName}//${dbName}?</Address>
<!-- endif -->

Note that the “else” part isn’t commented out. That’s so that if the preprocessor is off, it will recognize it as normal text and BTDF will process accordingly.  Also notice that the “Address” part is identical. This is because I wanted it to work the same way regardless of whether we were going to require the preprocess directive or not. If I wanted to do something different I would simply change these values.

Cumulative Update 1 for BizTalk 2016 Now Available

The first cumulative update for BizTalk 2016 is now available!  Find out more here: https://blogs.msdn.microsoft.com/biztalk_server_team_blog/2017/01/27/announcing-biztalk-server-2016-cumulative-update-pack-1/

 

Azure Logic Apps: 405 – Method Not Supported Errors from HttpListener

This one starts with a joke:

A gentleman walks up to a wall and starts banging his head against it.  Hard.  In fact, he bangs his head so hard, that people around grow concerned and one person says to him, “Sir, why do you keep banging your head against the wall?”  He replies, “Because it feels so good when I stop.”

So, like the gentleman in the above joke, I’ve been (figuratively) banging my head against the wall while trying to figure out how to invoke a Logic App I have deployed to the Azure cloud via an HttpListener.

I was using a PostAsync() call on the HttpClient to invoke the listener, but kept getting a 405 - Method Not Supported exception from the service. I was pretty sure POST should have been allowed! After checking the address, double-checking all the configurations, and so forth I couldn’t figure out why I would get the response I got (hence, the figurative banging of my head against a wall).

As is often the case, I found the answer in a post on an MSDN forum. When I copied the URL from the API definition of my HttpListener in Azure, it began with http instead of https, which was required.  A simple mistake and easy to miss.

After making the URL correction, adding an “s” to http, my calls to the service worked just fine.

And it feels really good now that I’ve stopped banging my head against the wall.