国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

Hello, WSGI

array_huang / 1574人閱讀

摘要：最新的工作中，有一部分的任務，于是開始折騰先惡補理論吧，關于有篇需要看，和，前者是年的提案，后者在年對前者做了小幅修訂，提案狀態也已經是，所以已經不是提案，已經是協議規范了，是的縮寫，解決的是各種比如與各種框架比如之間互聯互通的兼容性問題如

最新的工作中，有一部分HTTP API的任務，于是開始折騰Python WSGI...

WSGI

先惡補理論吧，關于Python WSGI有2篇PEP需要看，PEP 0333和PEP 3333，前者是2003年的提案，后者在2010年對前者做了小幅修訂，提案狀態也已經是“Final”，所以已經不是“提案”，已經是協議規范了；

WSGI，是“Python Web Server Gateway Interface”的縮寫，解決的是各種Web Server（比如Apache、Nginx）與各種Python Web框架（比如Flask、Tornado）之間互聯互通的兼容性問題；

如PEP中描述，在沒有一個統一協議規范以前，某個Python應用（Web框架、或者應用程序），可能僅支持運行在某一個Web Server下，應用開發者選擇某個Web框架的同時，也就綁死了某個Web Server；另外，在某個Web框架寫的應用代碼，遷移到另外一個Web框架，不一定能跑起來；所以，為了能讓用戶自由選擇、組合使用任意的Web框架和Web Server，該PEP規范了必要的交互方式和數據結構；

注意，WSGI不是一個軟件工具，它是一種協議規范的描述，它規范了“交互方式和數據結構”，任何Web Server、Gateway和Framework、Application，只要遵從這個規范去實現，就一定能互聯互通；既然是“交互”，就一定至少包含兩方吧，PEP指出：

the "server" or "gateway" side（下文稱為“server端”）

the "application" or "framework" side（下文稱為“application端”，framework本質上也是一種應用）

“application端”，必須提供一個“可調用的對象”供“server端”調用，“可調用的對象”一般是個入口函數，應用對HTTP請求的處理，要在這個入口函數內完成，函數最終返回HTTP Respone，比如生成的HTML；

下面的示例摘自PEP 3333：

pythonHELLO_WORLD = b"Hello world!
"

def simple_app(environ, start_response):
    """Simplest possible application object"""
    status = "200 OK"
    response_headers = [("Content-type", "text/plain")]
    start_response(status, response_headers)
    return [HELLO_WORLD]

“server端”，一般就是Web Server啦，最主要的任務就是接受到HTTP請求后，調用“application端提供的入口函數（比如上面的“simple_app”），另外應用程序里可能需要很多HTTP請求的信息（比如HTTP Method，GET/POST），這些信息，如何獲取呢？需要“server端”在調用應用入口函數的時候作為函數參數傳遞，就是上面的“environ”，關于“environ”這個數據結構的規范，PEP中也是有詳細描述的；

關于“server端”實現的實例代碼，稍稍復雜一點，搬運到這里，也不見得幫助理解，自行到PEP 3333查閱吧；

關于Python WSGI的理論介紹，最核心的都在這兒了，更細節的協議介紹，自行查閱吧；

Quick Start

好了，終于可以動手實踐了，早已按耐不住啦！我們先把上面的“simple_app”跑起來吧；

bash$ touch simple_app.py
$ vim simple_app.py

HELLO_WORLD = b"Hello world!
"

def application(environ, start_response):
    """Simplest possible application object"""
    status = "200 OK"
    response_headers = [("Content-type", "text/plain")]
    start_response(status, response_headers)
    return [HELLO_WORLD]

好了，“application端”已經好了，那“server端”呢？我們需要搞來一個實現了Python WSGI的Web Server，這里，我選擇了，uWSGI，不要被它的名字迷惑，它其實是一個功能非常全、實現了各種協議、支持各種的語言的“a full stack for building hosting services”，因為最早支持Python，所以取了這樣一個名字，官方都說，名字已經支撐不起它的野心，哈哈；

本實踐中，我們要基于Python安裝uWSGI：

bash$ pip install uwsgi

根據你的Python安裝路徑，uWSGI的二進制程序安裝路徑也會不同，比我電腦上：

bash$ ls /usr/local/python2.7/bin/uwsgi

現在，“application端”和“server端”，都已經準備就緒了，我們可以啟動的這個簡單的WSGI應用了：

bashuwsgi --http :9090 --wsgi-file simple_app.py

uWSGI會到simple_app.py文件中，找一個固定名字“application”的入口函數，當uWSGI收到HTTP請求時，就會調用該入口函數；

你在瀏覽器請求http://127.0.0.1:9090，應該會看到uWSGI的輸出：

bash$ uwsgi --http :9090 --wsgi-file simple_app.py

[pid: 1492|app: 0|req: 1/1] 127.0.0.1 () {34 vars in 626 bytes} [Sat Jun 20 15:32:14 2015] GET / => generated 11 bytes in 0 msecs (HTTP/1.1 200) 1 headers in 44 bytes (1 switches on core 0)
[pid: 1492|app: 0|req: 2/2] 127.0.0.1 () {36 vars in 615 bytes} [Sat Jun 20 15:32:14 2015] GET /favicon.ico => generated 11 bytes in 0 msecs (HTTP/1.1 200) 1 headers in 44 bytes (1 switches on core 0)

此時，你的瀏覽器應該也已經有“Hello World”頁面輸出，大功告成！

Learn More

本文的“Hello World”示例，僅僅是展示Python WSGI的框架結構，“server端”提供的HTTP請求信息“environ”完全沒有使用，無腦返回一個不變的字符串；

真正的應用，是需要根據功能要求，定制、填充那個application的入口函數的，應用開發者，可以自己代碼實現，也可以依托于一些流行的WSGI框架和Python模塊，比如：Flask框架、werkzeug

“server端”就沒有什么發揮的空間了，選擇一個支持WSGI協議的就好了，就像本文嘗試的uWSGI，除非你想自己實現個Web Server；Nginx雖然不直接支持WSGI，但它支持uWSGI，這樣把Nginx擋在uWSGI前面，uWSGI就可以專門處理動態的WSGI請求了，形成的架構，非常類似于PHP場景下的Nginx+PHP-FPM；

這些方面的知識，也許會有后續的文章做介紹；

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/45372.html

相關文章

  • 如何理解Nginx, WSGI, Flask之間的關系

    摘要：通過查閱了些資料，總算把它們的關系理清了。在這個過程中，服務器的作用是接收請求處理請求返回響應服務器是一類特殊的服務器，其作用是主要是接收請求并返回響應。正是為了替代而出現的。三結語最后以，，之間的對話結束本文。 剛轉行互聯網行業，聽到了許多名詞：Flask、Django、WSGI、 Nginx、Apache等等，一直無法搞清楚這些開源項目之間的關系，直至看到這篇文章后感覺醍醐灌頂，以...

    魏明 評論0 收藏0

  • web.py源碼分析: application(1)

    摘要：本文主要分析的是庫的這個模塊中的代碼。將結果轉換成一個迭代器。函數函數的定義如下位置位置位置該函數的參數中就是，是路由映射表則是，是本次請求路徑。位置，如果是其他情況，比如直接指定一個類對象作為處理對象。 本文主要分析的是web.py庫的application.py這個模塊中的代碼。總的來說，這個模塊主要實現了WSGI兼容的接口，以便應用程序能夠被WSGI應用服務器調用。WSGI是We...

    edgardeng 評論0 收藏0

  • WSGI規范筆記

    摘要：概述接口包含兩方面及。另外在和之間還可能有一種稱作的中間件。接收的返回值作為響應體。假設一個符合標準的可調用對象，它接受可調用對象作為參數，返回一個可調用對象的對象。這樣的可調用對象稱為。的概念非常接近。 概述 WSGI接口包含兩方面：server/gateway 及 application/framework。 server調用由application提供的可調用對象。 另外在se...

    wh469012917 評論0 收藏0

  • Werkzeug 與 WSGI 介紹

    摘要：在介紹之前，先介紹一下，它為語言定義的服務器和應用程序或框架之間的一種簡單而通用的接口。這個函數接受兩個參數，分別是和。響應對象是一個應用，提供了更好的方法來創建響應。這部分解釋來源于官方文檔的中文版。 Werkzeug 是一個WSGI工具包，也可以作為一個Web框架的底層庫。 WSGI 在介紹Werkzeug之前，先介紹一下 WSGI（Python Web Server Gate...

    mengera88 評論0 收藏0

發表評論

0條評論

最新活動
閱讀需要支付1元查看
<