Cookies in AL coming back to bite you!

Here’s a story from the trenches about a subtle change in Business Central 2024 Wave 1 that almost knocked us out for a couple of days. Check out the video to learn what stumped us:

https://youtu.be/zk3UPwSIk1o

In this video, Erik shares a real-world debugging story that cost his team a couple of days of head-scratching. A perfectly working app suddenly broke when upgrading from Business Central 23 to Business Central 24 — and the culprit turned out to be a subtle change in how HTTP cookies are handled during redirects. If you’re making HTTP calls from AL that involve authentication and redirects, this one could save you serious time.

The Scenario: A Simple HTTP Call That Worked… Until It Didn’t

Erik’s team had an app — nothing exotic, just a client customization — that made HTTP calls to an external website. The app passed credentials, fetched a page, and everything worked perfectly. Here’s the simplified version of the scenario:

  • The app calls Test Page 1, passing authentication credentials (in this case, via query string)
  • Test Page 1 authenticates the user and returns a 302 redirect to Test Page 2
  • The HTTP client follows the redirect automatically and returns the content from Test Page 2

This is a completely standard pattern. The HttpClient.Send method in AL handles 302 redirects internally — when it gets a redirect response, it automatically follows it to the new location. No extra code needed.

The Problem: Same Code, Different Results

Here’s where things got interesting. Erik deployed the exact same app to two different environments:

  • Business Central 23: Everything works perfectly. The expected page content is returned.
  • Business Central 24: The app returns the login page instead of the expected content.

To make things even more confusing:

  • Pasting the URL directly into a browser — works
  • Sending the request via Postman — works
  • Sending the request from AL code in BC24 — does not work

The code hadn’t changed at all. So what was going on?

Digging Into the Root Cause

To understand the issue, you need to understand what happens during the authentication and redirect flow:

  1. The first call to Test Page 1 sends credentials and authenticates successfully
  2. The server responds with a 302 redirect and sets a session cookie
  3. The HTTP client follows the redirect to Test Page 2
  4. Test Page 2 needs the session cookie to know the user is authenticated

You can verify this by opening browser dev tools — the first request to Test Page 1 returns a 302, the second request to Test Page 2 returns a 200, and the cookie is preserved across both requests.

The realization Erik’s team came to was this: in BC24, when the HTTP client follows a 302 redirect internally, it does not preserve the cookies. The session cookie received from the first response is discarded before making the redirect request. Without the cookie, Test Page 2 sees an unauthenticated user and returns the login page.

The Fix: UseResponseCookies

Business Central 24 introduced a new feature: explicit cookie support on the HttpClient. This is the UseResponseCookies property, which tells the client to preserve cookies received from responses and send them along with subsequent requests — including redirects made internally.

The fix was a single line of code:

Client.UseResponseCookies(true);

By adding this line before making the HTTP call, the cookies from the 302 response are preserved and sent along with the redirected request. After deploying the updated app to BC24 — it works.

Is This a Bug or Intended Behavior?

Erik leaves this question open for Microsoft to answer. In BC23, cookies were implicitly preserved during redirects — the HTTP client just handled it. In BC24, with the introduction of explicit cookie support, the implicit behavior apparently changed. Whether this is by design or an unintended side effect, the practical impact is clear:

A perfectly working app in BC23 can break in BC24 if it relies on HTTP calls that involve authentication with session cookies and 302 redirects.

Key Takeaways

  • BC24 changed how cookies are handled during HTTP redirects. Cookies from 302 responses are no longer automatically preserved during the internal redirect.
  • The fix is simple: Add Client.UseResponseCookies(true) before your HTTP calls.
  • If you’re upgrading to BC24 and have apps that make HTTP calls to services involving authentication and redirects, test them carefully.
  • If you see symptoms like getting login pages or authentication failures from HTTP calls that previously worked, cookie handling during redirects is likely the culprit.

This is one of those subtle platform changes that won’t show up in your code reviews or static analysis — the code is fine, it’s the runtime behavior that changed. Now you know, and hopefully it saves you the couple of days Erik’s team spent tracking it down.

Picture of hougaard

hougaard