SAP ABAP應用服務器的HTTP響應狀態碼怎么解決

本篇內容介紹了“SAP ABAP應用服務器的HTTP響應狀態碼怎么解決”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

在開發過程中發現該API工作不太穩定，同樣的輸入，時不時會返回HTTP 400 Bad Request：Encountered an error (InternalServerError) from host runtime

這個錯誤并不是總能重現。

通過排查，最后我們確認這個問題和我們調用API的代碼無關，于是給Azure報了一個bug:

在分析定位問題時，不由得讓我懷念起以前在ABAP On-Premise上做開發的一個便利之處——大多數問題都可以通過在ABAP應用服務器端調試來找到根源。

本文記錄了2016年時，SAP成都研究院CRM開發團隊在開發SAP CRM Fiori應用時的一些技術討論，關于HTTP請求的響應狀態碼的差異。

當時我們用Chrome打開SAP Fiori應用，在Chrome開發者工具的network標簽里，觀察到有的請求響應碼為HTTP 200，有的卻是HTTP 304.

HTTP 200和HTTP 304理論上的差異解析，網上一搜一大把：

https://ions/1665082/what-is-the-difference-between-http-status-code-200-cache-vs-status-code-304

本文我們從一個實際的例子出發，觀察ABAP服務器分別是在何種情況下，返回HTTP 200和304這兩個狀態碼的，幫助大家加深理解。

分幾種情況進行討論。

• 第一種情況：HTTP 200 OK

• 第二種情況：HTTP 304 Not Modified

• 第三種情況：HTTP 200(from Cache)

首先進行第一輪測試。

將這種來自SAP UI5標準庫文件的url粘貼到瀏覽器里訪問：

https://:7080/sap/bc/ui5_ui5/ui2/ushell/resources/~20160308134900~/sap/fiori/core-min-0.js

得到HTTP 200狀態碼：

大家想過沒有，上圖高亮的HTTP響應頭部字段，比如last-modified, 是在ABAP服務器上哪段代碼里被填充的？

靈活運用Jerry 文章  SAP錯誤消息調試之七種武器：讓所有的錯誤消息都能被定位 介紹的辦法，順利通過調試的方式，找到準確的位置如下：

上述代碼的邏輯：

(1) 第九行，服務器試圖從HTTP請求的頭部字段中，提取名為If-Modified-Since的字段值，因為這是我第一次請求該JavaScript文件，而這個字段的值邏輯上應該等于第一次請求到達服務器后，從服務器返回的響應結構里名為last-modified字段的值。

在我的第一輪測試里，因為是第一次請求該文件，HTTP請求頭部沒有包含If-Modified-Since字段，所以服務器解析出的值為空，即變量lv_modified_since為空。

(2) 在我使用的ABAP服務器上，JavaScript文件core-min-0.js最后修改的時間戳為20160316205045. 因此，兩個變量lv_change_time_char和lv_change_time_string都被附上了這個值。

下面第20行代碼展示了前文HTTP 200狀態碼的截圖里，HTTP響應字段cache-control被填充的地方。

第二種情況：HTTP 304 Not Modified

之前Chrome瀏覽器里打開的url：

https://:7080/sap/bc/ui5_ui5/ui2/ushell/resources/~20160308134900~/sap/fiori/core-min-0.js

不用關閉這個瀏覽器窗口，直接按F5刷新，這次收到的響應碼不再是HTTP 200 OK，而是HTTP 304 Not Modified.

為什么會產生這種差異呢？按F5之后仔細觀察請求頭部，發現第二次請求，瀏覽器發出的HTTP請求里，If-Modified-Since字段包含的就是第一個請求里從服務器端返回的last-modified字段值。

按F5刷新的這個請求到了服務器端，這一次ABAP服務器成功解析出請求字段If-Modified-Since的值：

將客戶端發送過來的這個If-Modified-Since時間戳，同服務器端該文件最后修改的時間戳進行比較(即下圖第26行AND后的第二個判斷條件），發現二者相等，因此在第28行返回HTTP 304 Not Modified.

第三種情況：HTTP 200(from Cache)

關掉Chrome，再打開，再訪問同一url，此時Chrome直接從自身的cache里返回該JavaScript文件，而不是向ABAP服務器上發起請求。因此服務器上所有ABAP斷點均不會觸發。

再回到Jerry遇到的那個Azure上執行function創建API遇到的HTTP 400 Bad request的incident，至本文發稿時為止還是未能得到解決。

盡管Azure的Function Host運行時也是開源的，但不能調試，我拿著這些海量代碼也沒轍，目前Github上看到的就有多達967個開著的 issue.

“SAP ABAP應用服務器的HTTP響應狀態碼怎么解決”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！