Worker fails on malformed query string

Hi team,

Our worker is throwing an error as we have a malformed URL with a %D in the URL:

https://www.[domain].com/any-url?varname=value%Dumbvar

You can test it by adding this to any URL that uses workers:

?varname=value%Dumbvar

Even this fails:
`

addEventListener(‘fetch’, event => {
event.respondWith(handleRequest(event.request))
})

async function handleRequest(request) {
try {
return new Response(‘Success’, {});
} catch (e) {
console.log(e);
return new Response(‘Whoops! the website is down.’,
{ status: 500, statusText: ‘Internal Server Error’ });
}
}
`

We just need to be able to read the URL and redirect it to the correct place.

That sure doesn’t look like valid syntax for a URL. When I search for “percent in a URL”, all responses talk about Percent Encoding. What if you use %25 instead of the percent sign?

We’re not generating this URL. This is a url where someone has added the % in the var and it is throwing the error, and showing up in our google search console as a 500 error.

We just need to be able to remove the invalid var and redirect it, but cant do anything as the worker just crashes.

You should be able to do some of that with Transform (Rewrite URL) and/or Redirect Rules.

https://developers.cloudflare.com/rules/transform/

Using transform rules would be a band aid to this one variation, and not a fix for workers.

We could transform this one URL variation, but it doesn’t enable us to use workers on any other URL that someone throws at our server.

Ok, you may want to head over to the Discord server to get help with your error checking in the Worker.

It doesn’t for me:

When did you create this Worker? This issue with the URL parser was fixed in 2022 but is gated through compatability dates: https://developers.cloudflare.com/workers/configuration/compatibility-dates/#new-url-parser-implementation

  • The original implementation would throw "TypeError: Invalid URL string." if it encountered invalid percent-encoded escape sequences, like https://example.com/a%%b.

If you created the Worker from the dashboard its compatibility date will be set to the current date on creation, and if you created it with the old version of the Quick Edit (Around May 2023) then it will have the oldest possible compatibility date.

Please try making a new Worker and reproducing the issue there. If you prefer Wrangler CLI, set your compatibility date to after 2022-10-31: Compatibility dates · Cloudflare Workers docs

Set the compatibility date of your Worker to a date after 2022-10-31 or enable the url_standard compatibility flag to opt-in the fully spec compliant URL API implementation.

3 Likes

Thanks Erisa, this worker was created in Jan 2022.

1 Like

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.