Interesting thing ! edgegpt doesn't work the same manner, depending on context execution (WSServerHandshakeError: 403, message='Invalid response status')

[manatlan]

Hi @acheong08 , I think I've found something : we'll need to dive in.

On a same machine (py 3.10.7 under Debian GNU/Linux 10 (buster))

I've built a simple command line to make an interaction with edgegpt

#!/usr/bin/python3 -u
# -*- coding: utf-8 -*-
import os,sys,re

from EdgeGPT.EdgeGPT import Chatbot
from EdgeGPT.EdgeGPT import ConversationStyle

import asyncio
import json
 
async def edgegpt( prompt, mode="balanced",authfile=None):

    cs={
        "precise":ConversationStyle.precise,
        "balanced":ConversationStyle.balanced,
        "creative":ConversationStyle.creative,
    }[mode]

    if authfile:
        cookies = json.loads(open(authfile, encoding="utf-8").read())
        bot = await Chatbot.create(cookies=cookies) 
    else:
        bot = await Chatbot.create()  # Passing cookies is "optional", as explained above

    response = await bot.ask(
        prompt=prompt,
        conversation_style=cs,
    )
    
    await bot.close()

    print( json.dumps(response,indent=4) )


if __name__=="__main__":
    _,prompt,*a=sys.argv
    asyncio.run( edgegpt(prompt,*a) )

If I call this, thru console : it works as expected, in all cases

$ ./edgegpt.py "hello world"

and print the json from bing (as excpected !)

If I call it from a webserver loop (on the same machine, in a starlette context) like that :

. . .
txt="hello world"
cmd='''./edgegpt.py "%s"''' % txt
x=subprocess.getstatusoutput(cmd)[1]
print("<pre>",x)
. . .

it will never work ... raising :

aiohttp.client_exceptions.WSServerHandshakeError: 403, message='Invalid response status', url=URL('wss://sydney.bing.com/sydney/ChatHub')
[08/Jun/2023:13:43:30 +0200] [upstream] [1657259] STDERR: Unclosed client session

So, clearly ... there is something, in edgegpt, or lower layers (aio ?) which seems to be wrong, and break the context ...

any idea ?

[acheong08]

No idea why this would happen. Does the same thing happen with older versions using websocket-client rather than aiohttp?

[manatlan]

Don't think is a trouble with aiohttp over old websocket-client ... (aiohttp is very robust and well tested)
But I'm pretty sure, that my hosting provider (in my case of web context / starlette) doesn't allow to set its own ssl context (cacerts from certifi)
(like in chathub.py, line 30), and override certify or things like that ... to be sure that a web app can't set its own cacert ;-(
which result in a "WSServerHandshakeError" error ;-(

So I think that the "wss sydney" propably use a cacert that is not known from my hosting provider ...
And the trouble would resolve, from itselft, when he will update its cacerts ;-(

it's probably the root cause ;-(
So that's trouble seems very specific to me ;-(

I will see that with my hosting provider ;-(

but perhaps, you'll right ... because, in the past ... no trouble of wss handshakes ;-(
I will dive into that

[manatlan]

Bingo .... you've right @acheong08 !!!!

No idea why this would happen. Does the same thing happen with older versions using websocket-client rather than aiohttp?

it works with "0.8.2" ! and doesn't work after this version ;-(
For now, I will stay on "0.8.2" ;-(

[acheong08]

rip

[manatlan]

@acheong08
When browsing the 0.8.2 tree : edgegpt was already using aiohttp ...
and this version doesn't have this trouble at this time !

Can you point me on some big changes between 0.8.2 and the latest, which could be the source of this trouble (403/handshake) ?
I can have a look

[manatlan]

@acheong08
forget that trouble ...

I've tested on another machine (my desktop/ubuntu)
and it works as expected ...

so it's very specific to me (my hosting provider config and edgegpt >0.8.2)
But versions>0.8.2 can cause this trouble in some circumstances