nginx 302和304的區(qū)別？302:請求的資源現(xiàn)在臨時響應來自不同URI的請求。因為這種重定向是臨時的，所以客戶端應該繼續(xù)向原始地址發(fā)送未來的請求。只有在緩存控制中指定或過期時，此響應才可緩存。

nginx 302和304的區(qū)別？

302:請求的資源現(xiàn)在臨時響應來自不同URI的請求。因為這種重定向是臨時的，所以客戶端應該繼續(xù)向原始地址發(fā)送未來的請求。只有在緩存控制中指定或過期時，此響應才可緩存。新的臨時URI應該在響應的location字段中返回。除非這是一個head請求，否則響應的實體應該包含一個指向新URI的超鏈接和一個簡短的描述。如果這不是get或head請求，除非用戶確認，否則瀏覽器不會自動重定向，因為請求的條件可能會更改。304:如果客戶端發(fā)送條件get請求，并且請求已被允許，但文檔的內(nèi)容（自上次訪問以來或根據(jù)請求條件）沒有更改，則服務器應返回此狀態(tài)代碼。304響應不包含消息的主體，因此它總是以頭之后的第一個空行結(jié)束。

pythonpost請求重定向怎么辦？

重定向和請求歷史默認情況下，請求自動處理除head以外的所有重定向。可以使用響應對象的history方法來跟蹤重定向。響應.歷史記錄這是一個：類：Response<requests.Response>為完成請求而創(chuàng)建的對象的列表。對象列表按最早的請求到最近的請求排序。例如，GitHub將所有HTTP請求重定向到HTTPS。：r=請求。獲?。ā啊保﹔。urlr.status編碼器歷史如果您使用的是get、options、post、put、patch或delete，則可以使用allowRedirections參數(shù)disable redirection processing:R=請求。獲?。ā啊?，allow redirects=False）r.status編碼器歷史如果你用的是頭，也可以啟用重定向：R=請求.head（“”，allow redirects=True）r。urlr.歷史