我有一個每日cron,它可以處理我應用程序中的一些循環事件,並且我不時注意到在日誌中彈出一個奇怪的錯誤。除此之外,cron還對一些代碼進行了驗證,並且它使用運行在同一服務器上的webapp,因此驗證請求通過POST
請求獲得一些數據。使用GET代替POST請求的python-requests
url = 'https://example.com/validate/'
payload = {'pin': pin, 'sku': sku, 'phone': phone, 'AR': True}
validation_post = requests.post(url, data=payload)
因此,這使得實際的請求和我登錄響應。不時,最近到請求的50%時,響應包含從nginx的以下消息:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<title>405 Method Not Allowed</title>
<h1>Method Not Allowed</h1>
<p>The method GET is not allowed for the requested URL.</p>
所以,實際的請求是使用GET方法制造,而不是POST正如代碼中所指示的那樣。在nginx的access.log
我可以看到該條目:
123.123.123.123 - - [18/Feb/2015:12:26:50 -0500] "GET /validate/ HTTP/1.1" 405 182 "-" "python-requests/2.2.1 CPython/2.7.6 Linux/3.13.0-37-generic"
而且uwsgi日誌應用程序顯示了類似的事情:
[pid: 6888|app: 0|req: 1589/58763] 123.123.123.123() {40 vars in 613 bytes} [Mon Apr 6 11:42:41 2015] GET /validate/ => generated 182 bytes in 1 msecs (HTTP/1.1 405) 4 headers in 234 bytes (1 switches on core 0)
所以,一切都指出,實際的請求不使用發POST。處理此碼應用程式路線簡單,這是摘錄: @ app.route( '/驗證/',方法= [ 'POST']) @login_required
def validate():
if isinstance(current_user.user, Sales):
try:
#do the stuff here
except Exception, e:
app.logger.exception(str(e))
return 0
abort(403)
該應用路線可以在try
塊中有一些returns
,但即使這些失敗或存在表示,也沒有任何東西可以引起此塊中的405
錯誤代碼,只有403
這是很少發生的,因爲我手動構建和登錄用戶來自cron。
我發現了類似的東西here,但有人說,有一個從HTTP重定向到HTTPS版本,並且我也有重定向存在於服務器中,但是請求所在的URL有HTTPS ,所以我懷疑這是事業。
我正在運行的這個堆棧是uwsgi
+ nginx
+ flask
。任何人都可以看到可能造成這種情況?重複一次,它不會總是發生,所以有時它的工作如預期,有時不會。我最近從apache
和mod_wsgi
遷移到這個新的堆棧,從那時起,我已經開始傳遞這個錯誤;不能回想起在apache
環境中看到它。
謝謝!
感謝您的回覆。我用這個標誌修改了我的應用程序中的調用,並添加了一些調試信息以查看是什麼導致了這種情況。 –
我知道這似乎令人煩惱,但我想向您保證,我們正在做的是目前處理重定向的最佳做法。請求中發生的事情是爲了您的安全。 –