Bug fix: URL encoding preserved in Function event

We are about to roll out a bugfix to our Functions engine. I expect this change to be rolling out on the 9th of December.

The Bug

Previously we did decode request URLs when a request for a function came in. In the future we will keep the encoding in place. This means your function code needs to handle url decoding itself. See the following example for the specifics and why it is useful.

Example

Let’s say we have a function called hello and this redirect in the netlify.toml:

[[redirects]]
from = "/somePage/:someVar"
to = "/.netlify/functions/hello"
status = 200
force = true

(This means all request to /somePage/ with any single-element suffix will be routed to the function.)

Now consider this Request:
https://my-site.netlify.app/somePage/http%3A%2F%2Fexample.com%2F

Function payload

This is what the event object passed into the function looks like before and after our fix.

Before:

{
  path: '/somePage/http://example.com/',
  // ...
}

After:

{
  path: '/somePage/http%3A%2F%2Fexample.com%2F',
  // ...
}

Why do we need to keep the url encoded?

This is crucial for any code that wants to extract so-called “path parameters” from the URL path. If the parameter itself contains an urlencoded slash and we decode it early on, the function code cannot properly determine where the part of the path ends that we want to extract.

This was first reported in our NextJS compatibility layer - see this issue for a more complete reproduction of the bug: getServerSideProps fails for certain values, probably related to URL encoding or slashes · Issue #98 · netlify/next-on-netlify · GitHub

Could this break existing functions?

Yes it could. If your code relies on the previous behaviour of Netlify decoding the url then you might want to check if you need to adjust your function code. You can use decodeURI to decode URL paths.

We have done some inspection of our incoming traffic and think that very few functions use this pattern. Less than .01% of our accounts have any traffic matching this pattern, in the past 24 hours.

Please let us know if you have any questions around this change and what it would mean for your existing functions or code you write in the future.

4 Likes

This is rolling out right now…

Hi Markus,

TL; DR NextJS projects on Netlify might be broken right now regarding getServerSideProps

In details: https://github.com/netlify/next-on-netlify/issues/98#issuecomment-741890295

Thanks, Philippe, our team is rolling back the change and will investigate this.

2 Likes

Thank you Chris. I confirm the rollback is effective.

1 Like

appreciate that heads up! We’ll talk internally about next steps and follow up here as things develop.

1 Like

Hi Chris, will there be a postmortem included in the follow up? Thanks

Likely not a deep RCA, no. We rolled this out per this announcement, and the affected people were largely those who use cloudflare in certain ways very much against our advice:

… and in an unsupported configuration:

…were the ones impacted.

If you don’t proxy to us from cloudflare, we’d love to hear about the use case for your site that was impacted so we can make sure to avoid future breakage!

If you don’t proxy to us from cloudflare, we’d love to hear about the use case for your site that was impacted so we can make sure to avoid future breakage!

I can confirm we do not have a proxy in front of Netlify. We have a Next.js site deployed via next-on-netlify as per Philippe’s report above.

All of our Functions were affected.

We definitely introduced an unexpected regression here and I can make sure to write a small RCA for this.

1 Like

Hi @fool,

I don’t understand exactly how the SSL certificate issue connected with this URL encoding changes.

We have different DNS setup:

  • netlify handles the domain (at a registrator we only configured the netlify DNS records): app.brightmeup.ai
  • external registrator handles the DNS, we configured a CNAME record pointing to the netlify domain (app-hirspektrum-hu.netlify.app): app.hirspektrum.hu

We do not use any special proxy setup.

We had serious problems on Dec 9, 2020.
All of our lambda functions on all of our sites responded 404 http error for hours.

I don’t think we should be affected because this URL encoding changes.

We only use English letters, numbers and hyphen in the path part of the urls.
We use the gin (go lang) third party library and it handles the URL encoding with the query string part.
If it’s helping I can share an example public project on github about how we write/use lambda functions.

I’m curious what is count as an incident on your status page, because this incident still isn’t mentioned on it.
If/when we notice a problem, usually one of our first steps to check your status page and your status twitter account…

Best Regards,
Zoltan Imre

Hi @negentropics, I think @fool’s previous statement around SSL and Cloudflare was incorrect. The issue with 404 function responses was caused by an unexpected regression, but @marcus mentioned a small RCA will be forthcoming.

Just a heads up: a change has been rolled out to production today - we should again be preserving url encoding in the functions request paths.