私は低レベル ネットワーキングの専門家ではないので、一般的なオープン Wi-Fi 認証の実装がクライアントにどのようにタグ付けされているかはわかりません。しかし、 OSIモデルでは、下位層は上位層について何も知らないというのが私には真実だと思われます。言い換えれば、IP は HTTP 用語とページ URL を具体的に認識していません。
このようにして、CherryPy をカスタマイズすることで取得できると思われるソケット参照を手元に置くと、URL ではなく、せいぜい元の IP アドレスが得られます。また、ネットワーク (IP) 層とアプリケーション (HTTP) 層を混在させ、一般に複数の場所で 1 つのアプリケーション エンティティを管理すると、あらゆる種類の問題が発生する可能性があります。たとえば、HTTP を話すエージェント、たとえばフォワード プロキシとリバース プロキシを扱う場合、下位層のニュアンスを予約しません。
アップデート
リクエスト URL もあると言うので、生のソケットを取得する方法は次のとおりです。ご覧のとおり、これは内部の奥深くにあり、本質的にエンド ユーザーが依存すべきではない実装の詳細です。これは契約の一部ではなく、次のバージョンで変更される可能性があります。したがって、自分の足を撃つ可能性が高くなります。
#!/usr/bin/env python
import cherrypy
config = {
'global' : {
'server.socket_host' : '127.0.0.1',
'server.socket_port' : 8080,
'server.thread_pool' : 8
},
}
class App:
@cherrypy.expose
def index(self):
'''For caveats and details on the slippery slope, take a look at ws4py
https://github.com/Lawouach/WebSocket-for-Python/blob/master/ws4py/server/cherrypyserver.py
'''
print(cherrypy.serving.request.rfile.rfile._sock)
return 'Make sure you know what you are doing.'
if __name__ == '__main__':
cherrypy.quickstart(App(), '/', config)