How to pass a url contains ? , / , & inside flask webservice method

Question

I am trying to pass a URL inside a Flask method,

My url: https://example.org/de?=fg&hi=jk

I tried the below steps:

@app.route('/flip/<path:url>')
def flip(url):
    return "retrievved url:"+str(url)
    
calling the url : localhost:8200//flip/https://example.org/de?=fg&hi=jk 
returns : `https://example.org/de`

and another method,

@app.route('/flip')
def flip(url):
    url=request.args.get('url')
    return "retrievved url:"+str(url)

    
calling the url: localhost:8200//flip?url=https://example.org/de?=fg&hi=jk  
returns : 'https://example.org/de?=fg'

My expected output should return the entire url we are passing https://example.org/de?=fg&hi=jk

Answer 1

This has nothing to do with Flask. Your URLs don't mean what you think they mean.

For example, this URL:

localhost:8200//flip?url=https://example.org/de?=fg&hi=jk 

… has two query parameters:

url=https://example.org/de?=fg
hi=jk

The & separates query parameters on the outer request, so it has separate url and hi parameters.

It's also illegal to have many of those characters in a query parameter in the first place, but you'll often get away with it.

---

This is why websites that need to embed URLs inside other URLs use percent encoding. Your page should be sending this:

localhost:8200//flip?url=https%3A//example.org/de%3F%3Dfg%26hi%3Djk

Now there's only one query parameter:

url=https%3A//example.org/de%3F%3Dfg%26hi%3Djk

And then, when you parse the query string, what you get is:

url=https://example.org/de?=fg&hi=jk 

---

If you really can't fix things on the client side, you may be able to iterate all the query parameters and trying to reassemble them into one url parameter.

Or you could get the entire URL (request.url instead of request.args), and do your own parsing on it manually instead of letting Flask or Python do it for you.

But either way, this is really hacky, and you shouldn't consider it unless absolutely necessary.

Plus, again, your URL is illegal, and you don't want to rely on "you'll often get away with it". Unless it's acceptable that, say, some users won't be able to connect because their proxy screws up the URLs, and you spent all weekend banging your head on the desk trying to debug it, and then it works for some of them but a few now get the wrong pages, and then the new version of Chrome is suddenly breaking something different, and…

HTTP is complicated and messy enough when you stick to the standards, especially since your framework does most of the heavy lifting for you.