Need help with { } curly braces in my uri query/path

Hello all, my company is very new to cloudflare and this has been a really challenging couple of weeks

I have a URL on our sharepoint site and if someone appends this to the end of the URL


it will prompt them for credentials and we want to prevent that with a transform rule, If I use this:

(http.request.uri.path matches "(/_(?i)layouts/(?i)userdisp.(?i)aspx)")

it rewrites the path as I want so long as they don’t put in {UserID} or anything in curly braces {supercalifragilisticexpialidocious} for that matter

{ doesn’t work
r# gives me all kinds of problems with wanting quotes or claiming repetitive character missing
({UserID}) = nope

I’ve tried all kinds of variations of http.request.uri.query matches … contains … eq, back to http.request.uri.path, back to http.request.uri

regex101 says I should be using this


but Cloudflare’s parser doesn’t like escaping slashes it seems

I would appreciate any help anyone can give pointing me in the right direction in the docs, unfortunately searching for { } gives a lot of results for when its used like "something in { ip range or sets } "

Thanks everyone :slight_smile:

When I say “{ doesn’t work” I mean “SLASH”“CURLY BRACE” apparently these community forums know how to part slash curly even if transform rules don’t! LOL :rofl:

Same thing here

Parens Open → Slash → Curly Open → .* → Slash → Curly Close → Parens Close

http.request.uri.path is just the path. The part you’re looking at with the curly braces is the query string, which is http.request.uri.query.

(Also, you have a Business plan, yes? You need that to use regexes in rules.)


Yes, Business,

The problem I’m having is it seems like the http.request.uri.path shouldn’t be affected by what’s in the http.request.uri.query. I have other transform expressions which are working fine with other URI’s which have queries. it’s just when there’s something in curly braces { }

I tried this:
((http.request.uri.path matches “(/(?i)layouts/(?i)userdisp.(?i)aspx)") or ((http.request.uri.path matches "(/(?i)layouts/(?i)userdisp.(?i)aspx)”) and (http.request.uri.query matches “({.*})”)))
[hopefully the \ 's show]

and this:
((http.request.uri.path matches “(/(?i)layouts/(?i)userdisp.(?i)aspx)") or ((http.request.uri.path matches "(/(?i)layouts/(?i)userdisp.(?i)aspx)”) and (http.request.uri.query matches “({.*})”)))

but the rewrite doesn’t happen.

I may have found the issue. I was able to make curly brace matching work with this:

My expression is:

(http.request.uri.path matches "^/foo"
and http.request.uri.query matches "\{.*\}")

Notice that the curly braces must be backslash-escaped to have literal meaning in a regular expression. Which of course you tried. But if you do it in the Expression Builder, where you click for a field and an operator and have the “and” and “or” buttons, any backslashes you enter in the text field are “helpfully” changed to double-backslashes in the actual expression. So you’re creating a regex that is looking for a literal backslash in front of the curly braces.

If you don’t use a backslash, the curly braces have special meaning.

So open the free-form expression field by clicking “Edit expression” and you can enter it correctly.


Ok I’ll try again and just have the one ‘path and query’, and not ‘((path) or (path and query))’ and see if it pans out

Yea this is definitely something wonky in their parsing the URI and the inability to escape the curly brace, if I go back to the expression builder and use ‘matches regex’ it will take { or not \\{

‘matches regex’ { doesn’t work

‘matches regex’ \{ doesn’t allow me to deploy

The expression builder recognizes that the \ is an escape character as we can see the \\ in the preview

I’ve also tried

http.request.full_uri contains “{”

http.request.uri.query contains “{”

http.request.uri.query contains “\{”

Think I’m going to have to open a support ticket

You need to use the free form expression field like @i40west demonstrated earlier. You won’t be able to do it with the drop-down form-based interface.

Sorry ,I should have shown that I did that.

Free form the expression will deploy, however when I attempt to browse my site Cloudflare is not rewriting

I have a second uri.path rule without the uri.query and if I put just URI


without any query it rewrites fine, if I query anything without { } it works fine, { breaks, } breaks so it’s something when the cloudflare front ends are parsing the string the { } is breaking the regex down I think

1 Like

Ok sorry, now I did a little more trial and error and it’s not specifically that it’s the { } so that makes me feel better it seems it’s anything ?id=*





if I send


it matches and rewrites, but as soon as id has a value it fails, so I tried

http.request.uri.query matches “^id=.*”


http.request.uri.query matches “id=.*”

no joy :frowning:

Okay, with much banging of my head, I have discovered that sometimes the curly braces are URL-normalized to %7B and %7D, and sometimes they are not.

This seems to work more reliably:

(http.request.uri.path matches "^/foo" and
http.request.uri.query matches "(%7B.*%7D|\{.*\})")

I say “more reliably” because it works in a browser but I can still bypass it with curl.

I’ll poke at this some more later.


Thanks!! :smile: that does seem to help with parsing for curly braces.

I’m still not rewriting when the uri.query has ?id=anything

I’ve opened a support ticket and see what they come back with

1 Like

That helped so much!!

I got what I needed and it seems to be working in my browser tests, I’ll start trying to break it in curl next :rofl:


A little easier to read hopefully:

Definitely needed the URL-encoding of the = character I think

Once @i40west pointed out that URL encoding for { = %7B and } = %7D I thought heck yea lets do URL-encoded characters for the = in id=… and it worked and then putting in .* after solved all the rest with the curly braces as well.

So funny in the end my topic name is inaccurate but hopefully if this all helps someone else down the road we’ve all made someone’s life easier :smile:

1 Like

Also adding in case this helps anyone else with Sharepoint woes, while I was testing, every page I tried to append a query of ?id=foo would take me to a page full of Cicero’s Lorem Ipsum

so I basically had to write a rule in front of all my other rules

( eq “” and http.request.uri.query matches “^(?i)id(%3d|=|\\=).*”)

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