Add Query Parameters for WebSocket

[lvelvee]

• [X] I have searched to see if a similar issue already exists.

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like

I just want to identify each request by parameters from gr.Request, so I think copying the query parameters to the websocket is a good idea.

current:

HTTP: http://127.0.0.1:7680/gradio/?someargs=value
WS: ws://127.0.0.1:7680/gradio/queue/join

expected:

HTTP: http://127.0.0.1:7680/gradio/?someargs=value
WS: ws://127.0.0.1:7680/gradio/queue/join?someargs=value

Additional context
Add any other context or screenshots about the feature request here.

under mount_gradio_app

[i008]

That would be really amazing ! Need this asap;) can anyone give pointers how this could be implemented? Maybe I can work on that.

[lvelvee]

@i008 just copying the params from http request to websocket request... I'm still working through the source code.

https://github.com/gradio-app/gradio/search?q=queue%2Fjoin

[abidlabs]

Hi folks, just following up on this. So just to confirm, you want to pass in your own query parameters to ws://127.0.0.1:7680/gradio/queue/join? Some questions?

• How would you access these query parameters in your backend function? Are you intending that these parameters are passed into the gr.Request() parameter?
• What information are these query parameters sending?

In general, if you can provide a minimal but complete code snippet of what you are trying to accomplish, it will help us implement the feature

[i008]

That's not what I meant. The thing is you can access your gradio app with query params (first gradio app open) And every subsequent function call will have the query parameters accessible in the gr.Request scope (accessing the referer header) afair. But if you launch the app in queued websock mode you can't access this information anymore.

On Tue 21. Feb 2023 at 15:33, Abubakar Abid @.***> wrote:

Hi folks, just following up on this. So just to confirm, you want to pass in your own query parameters to ws://127.0.0.1:7680/gradio/queue/join? Some questions?

• How would you access these query parameters in your backend function? Are you intending that these parameters are passed into the gr.Request() parameter?
• What information are these query parameters sending?

In general, if you can provide a minimal but complete code snippet of what you are trying to accomplish, it will help us implement the feature

— Reply to this email directly, view it on GitHub https://github.com/gradio-app/gradio/issues/3228#issuecomment-1438593669, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTZGEKN55KLEDOAYLMKEMTWYTG43ANCNFSM6AAAAAAVAB73O4 . You are receiving this because you were mentioned.Message ID: @.***>

[lvelvee]

@abidlabs

I'd like to add some flag (in the URL) for Gradio to interact with other applications (e.g., one-time authentication/automatically fill out forms, etc.). In my business, I want to restore the last state (reproduce the inputs) from my database. I think copying the parameters to the websocket is a good and simplest way to enhance flexibility.

[abidlabs]

Got it, yes I think we can do that, thanks for providing that clarification

[abidlabs]

One thing I want to understand is that this issue specifically mentions getting the query parameters when running with websockets (i.e. queuing enabled). However, as far as I can tell, the query parameters are not sent over even with regular http requests (i.e. when queuing is not enabled).

For example,

import gradio as gr

def predict(x, request: gr.Request):
    print(request.query_params)
    return x

gr.Interface(fn=predict,
             inputs="text",
             outputs='text').launch()

Then navigating to http://127.0.0.1:7860/?ab=cd (where this app is running) and submitting a prediction, does not print any query parameters for me.

Am I missing something? Or would this need to be implemented both for queuing enabled and disabled?

[i008]

So they are not showing in query_params if that's a bug or not, not sure. Maybe they do if you call the function directly using the exposed API and not the app itself.

But you can access them like that: headers = dict( [ (a[0].decode("utf-8"), a[1].decode("utf-8")) for a in gr.request.dict["scope"]["headers"] ] ) parsed = urlparse(headers["referer"]) query_params = parse_qs(parsed.query)

So you can always access the referer in the headers and it contains them for all requests, that is good enough for me.

Of course im talking about the http/rest mode. In queued mode its not possible to get this information whatsoever.

[abidlabs]

Hey @i008 @lvelvee would a solution like this work for you to access the query parameters? It should work with websockets too:

https://huggingface.co/spaces/radames/gradio-url-params/blob/main/app.py

[lvelvee]

@abidlabs copy params from html to websocket would be better.

We should only change here and related logics. https://github.com/gradio-app/gradio/blob/11bb732f5d12284aad1a139fd3891bd01ff1167d/ui/packages/client/src/client.ts#L260

This solution (https://huggingface.co/spaces/radames/gradio-url-params/blob/main/app.py) is too tricky, it requires additional javascript.

[abidlabs]

Hi @lvelvee I'm inclined against copying the query parameters to websocket as we may end up using query parameters in the future for some other purpose. Is there a reason why you can't use the _js parameter -- it exists for use cases like this, and unless there's some use case it doesn't support, I would be inclined to prefer this solution. You can see an active discussion with a full example here: https://github.com/gradio-app/gradio/discussions/2949#discussioncomment-5278991

[lvelvee]

Hi @abidlabs Thanks for your explanation. I see. It's reasonable if our user only running a gradio instance. But if someone would like implement some middleware mechanism for multiple instances.

[abidlabs]

Can you elaborate a little more about what you mean by a middleware mechanism for multiple instances?

[lvelvee]

@abidlabs it's may not be a common concern.

But for example, if someone would like to mount multiple Gradio instances onto a FastAPI site and add authentication or statistical middleware for all Gradio apps, query parameters would be useful. (Although we could implement it using cookies or other mechanisms.)

[hcaihao]

It works under "iframe" but not work under "gradio-app"

[abidlabs]

Hi folks. After looking into this, I don't think it's a good idea manually change the headers in the websocket requests. Given that there are workarounds mentioned above, it would be preferable to use those workarounds instead. I'll go ahead and close this issue

[JuvenileQ]

where should I find the queue/join interface usage documentation for ws

[speaknowpotato]

how to get url parameters such as access token quietly? #3665

hi @abidlabs , this link https://github.com/gradio-app/gradio/discussions/2949#discussioncomment-5278991 doesn't work now. can you help send a new one? thanks.

[blackmarkt]

Hi,

Thank you for posting this example: https://discuss.huggingface.co/t/refresh-ui-post-change-in-url-parameters/52654/2

But how can I access the url parameterslocally in the code so I can use them? None of the gradio components seem to have a return output of the url parameters.

Here is post I commented about this issue: https://discuss.huggingface.co/t/refresh-ui-post-change-in-url-parameters/52654/2

Thank you

[abidlabs]

Hi @blackmarkt you need to pass in a parameter of type gr.Request into your function, and that parameter will have access to the query parameters.

See https://www.gradio.app/docs/request for more info

[blackmarkt]

@abidlabs thank you for responding so quickly. Any chance you can provide a simple code example where the url parameters are passed on page load and then stored in a global variable? Looking at the classes load and Interface when you assign an output variables like init_values a gradio object is returned.

What I am looking to achieve is to get the url_parameters when the iframe is loaded and then use those variables to access a db.

Did that make sense?

Thank you.