question

BenDuguid avatar image
0 Votes"
BenDuguid asked RichDeBourke-8596 edited

Azure Front Door returns a 503 Service Unavailable when Range and Compression Headers are in the request

We're seeing an issue with our Front Door configuration where requests from the Facebook crawler are consistently seeing a 503 Service Unavailable error for all requests.

This seems to be related to the combination of request headers used:

 User-Agent: facebookexternalhit/1.1 (+http://www.facebook.com/externalhit_uatext.php)
 Accept-Encoding: deflate, gzip
 Range: bytes=0-524288
 Connection: close

Or in curl:

 curl -v --compressed -H "Range: bytes=0-524288" -H "Connection: close" -A "facebookexternalhit/1.1 (+http://www.facebook.com/externalhit_uatext.php)" "$URL"

Requesting the page without the Accept-Encoding correctly returns a 206 Partial Content response.

Sending the full request to the origin/backend host directly (Azure App Service) also returns a valid response with the expected page content.

I've seen (and replied to) the same issue reported here: https://feedback.azure.com/forums/217313-networking/suggestions/38617117

azure-front-door
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

BenDuguid avatar image
0 Votes"
BenDuguid answered

Apologies all for not coming back on this.

@SaiKishor-MSFT Not really, no. The end result is that the social site (or anything else using the range header in combination with gzip encoding) causes Front Door to return a 503 when the backend is healthy and responding correctly. These are dynamic sites, so it's likely that headers or similar are slightly different between requests.

@RichDeBourke-8596 Yes, we found the same, so I adjusted the rule to remove the Accepts-Encoding header if there was also a Range header. This ensures that all of these should work and get the correct 206 Partial response that is no larger than the requested value.

5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

BenDuguid avatar image
0 Votes"
BenDuguid answered

I have managed to implement the following work-around for now:

I've created a Rules Engine rule that removes the Accept-Encoding header when the User Agent begins with facebookexternal. This appears to be sufficient to stop Front Door from returning a 503 response, and at the moment the metadata on our pages fits within the requested range from Facebook, so this looks to be working at the moment.

It would be ideal if this could "just work" however.

5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

SaiKishor-MSFT avatar image
0 Votes"
SaiKishor-MSFT answered

@BenDuguid

The most common cause of the 503 is usually a request timed out or the backend is unhealthy. While I understand that range and compression headers may have caused it, have you tried increasing the timeout value and test again?

5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

BenDuguid avatar image
0 Votes"
BenDuguid answered

Hi, the 503 response was happening within about 5-10 seconds, well within the default 30 second timeout.

I did try increasing the timeout to 120 seconds, but we still saw the 503 response within 5 seconds.

As mentioned, making the same request, with the range and accept-encoding headers, directly to the back-end pool resulted in a valid 206 Partial response, and stripping out the accept-encoding header from the request with a rule also succeeds through the front door, so this looks to be more of an issue within front door than with our application.

5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

BenDuguid avatar image
0 Votes"
BenDuguid answered

We're seeing the same behaviour with LinkedIn sharing as well, however that's still throwing some sort of 503, but only reporting "Unable to connect to server. Bad DNS, bad gateway, or invalid server address."

Again, sharing the backend pool directly works successfully, so this is not an obvious error with our application.

5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

BenDuguid avatar image
0 Votes"
BenDuguid answered

Seems that it's the gzip encoding with the range header that's the problem:

 User-Agent: LinkedInBot/1.0 (compatible; Mozilla/5.0; Apache-HttpClient +http://www.linkedin.com)
 Range: bytes=0-524288
 Connection: close
 Accept-Encoding: deflate

Works as expected (206, although not compressed), while:

 User-Agent: LinkedInBot/1.0 (compatible; Mozilla/5.0; Apache-HttpClient +http://www.linkedin.com)
 Range: bytes=0-524288
 Connection: close
 Accept-Encoding: gzip

Returns the 503 error.

Removing the Range header, but including either of the compression encodings works as expected (200, compressed with gzip).

5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

BenDuguid avatar image
0 Votes"
BenDuguid answered

This appears to be happening on a number of clients, mostly when we've enabled the Rules Engine - for a couple of sites we have that don't have any rules in the Rules engine, we're not seeing this issue.

5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

SaiKishor-MSFT avatar image
0 Votes"
SaiKishor-MSFT answered RichDeBourke-8596 edited

@BenDuguid I did a little more investigation regarding this and here is the issue that causes this 503-

When range header is added, frontdoor will reach out to origin twice(or more). If origin returns inconsistent content, we’ll fail the request.

Hope this helps. Please let me know if you have any further questions. Thank you!

· 3
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

@BenDuguid Please let us know if the above answer helped you resolve your issue. Please do accept the answer as it helps others in the community. Thank you!

0 Votes 0 ·

@BenDuguid Any update? Please let us know if you have any further questions/concerns. Thank you!

0 Votes 0 ·

@SaiKishor-MSFT – I’m researching for a question on Stackoverflow that has the same problem – a 503 response to Facebook on a site with Azure Frontdoor.

You noted the problem is a request with a range header and Frontdoor “will reach out to origin.” You didn’t say what BenDuguid or others should do. Ben is adding a rule for FB and LinkedIn – he’s removing the range header (returning his entire page file?) and Frontdoor responds with a 200. He also can leave the range header in place and return the file using deflate – Frontdoor responds with a 206 but works on FB.

The complication is other apps request page information using the range header, such as WhatsApp (it’s not documented, but there are references to WhatsApp requesting the first 10K of a file). Is the only solution to setup a rule for every app that uses the range header and doesn’t response consistently?


0 Votes 0 ·