Possible to get headers of active connection to asyncio server implementation of ws4py?

35 views
Skip to first unread message

Andy Hawkins

unread,
Jul 20, 2015, 11:32:16 AM7/20/15
to ws...@googlegroups.com
I'm trying to get headers, more specifically cookies, from the overwrote opened method (or any method before or during received_message, really).

I'm using the current build from pip, everything is working fine as far as the echo server goes, just can't seem to find how to get headers from the WebSocketProtocol .

I see in the Protocol wrapper, that the headers are being read from a generator during the handshake, so I know their being processed, just not stored anywhere for access. I was curious if there was a way to access these via my WSServer class. I don't mind having to overwrite a method if possible and carry the maintained of updates to it as the code base is fairly small and easily diffed. I'm assuming I'm going to need to extend WebSocketProtocol into my own class and overwrite either read_headers or  handle_initial_handshake (I'd prefer the read_headers over handle hand shake for obvious reasons if this is my only option).

My intent is to incorporate the existing session handling of my previous application so that it can fail-over to regular ajax polling already implemented for non-evergreen browsers.
  
   # Actual SERVER.
def _server(self):
set_process_name(self.__nameFull__)
self.__loop = asyncio.get_event_loop()
   
def start_server():
factory = lambda: WebSocketProtocol(WSServer)
return self.__loop.create_server(factory, self.__bind, self.__port)

  s = self.__loop.run_until_complete(start_server())
      print(self.__nameFull__, 'serving on', s.sockets[0].getsockname())
self.__loop.run_forever()
print(self.__loop.is_running())

class WSServer(WebSocket):

def opened(self):
print("OPENED")
headers = yield from self.proto.read_headers()
print(headers.get('Cookie'))

def received_message(self, message):
# p(debug_object(self.connection))
# print("\n\n\n\n\n")
# p(debug_object(message))
self.send(message.data, message.is_binary)

Sylvain Hellegouarch

unread,
Jul 20, 2015, 11:40:24 AM7/20/15
to ws...@googlegroups.com
Hi,

Thanks for switching to the mailing-list.

--


This should be feasible indeed by simply injecting the headers to the websocket class, or make them available via the proto directly as you suggest.
However you can't call read_headers yourself. At that time, the headers have already been read from the request.

One question, would you expect to reject the websocket connection upon reading the headers? Or do you want a view on them for later processing? 

--

Andy Hawkins

unread,
Jul 20, 2015, 11:51:10 AM7/20/15
to ws...@googlegroups.com
Thank you for the quick response.

Beautiful code base by the way.

First question:
I don't plan on rejecting the connection or changing it's state at all, I simple would like the bridge the existing security session tokens that are all based in the cookies and various other headers of the existing communication api. If the session is considered invalid, I would make a new flow to distribute any new cookie/session to the browser over the websocket (maybe even make the client connection hangup manually and reconnect from inside the client logic).

Second question:
I would like to be able to view them and store them based on some unique connection identifier so that I can pass them along to the existing infrastructure on each received_message call to simulate the cgi style interaction already in place until I have more time to finish re-writing the old API into python.

~@

Sylvain Hellegouarch

unread,
Jul 21, 2015, 7:49:42 AM7/21/15
to ws...@googlegroups.com
Hi,

2015-07-20 17:51 GMT+02:00 Andy Hawkins <a90...@gmail.com>:
Thank you for the quick response.

Beautiful code base by the way.


Thank you very much :)
Though I believe it could much better.
 

First question:
I don't plan on rejecting the connection or changing it's state at all, I simple would like the bridge the existing security session tokens that are all based in the cookies and various other headers of the existing communication api. If the session is considered invalid, I would make a new flow to distribute any new cookie/session to the browser over the websocket (maybe even make the client connection hangup manually and reconnect from inside the client logic).


Okay. Sounds fair then.
I will try to provide something shortly enough and hopefully, this'll be suitable.
 
--

Andy Hawkins

unread,
Jul 21, 2015, 6:09:19 PM7/21/15
to ws4py
Thank you,

To continue working I just had the client extract the clients cookies and send them along with each payload as workaround for now.

I have another question for if you have a moment, at first glance it appears that message_received is blocking.

Like if I sent a few messages, and time.sleep was before self.send all the frames stack up and wait?


def received_message(self, message):
print(message.data)

time.sleep(10)

self.send(message.data, message.is_binary)

Even the print output results in the same outcome. Is there a way or design pattern (promise/deferred) to keep this from happening?

Thanks
~@ndy Hawkins

Andy Hawkins

unread,
Jul 21, 2015, 6:43:25 PM7/21/15
to ws4py
Actually, this requires more testing. Just noticing any long running subprocess inside message_receive is causing other messages from executing. Ignore the above for now.

Sylvain Hellegouarch

unread,
Jul 23, 2015, 2:31:43 PM7/23/15
to ws...@googlegroups.com
Hi,

I have set the following attributes now:


Let me know if that helps.


--
You received this message because you are subscribed to the Google Groups "ws4py" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ws4py+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply all
Reply to author
Forward
0 new messages