最近Jerry參與了SAP Commerce Cloud的標準開發，我們調用微軟雲平臺Azure上創建Lambda Function的Restful API來創建Lambda Function：
在開發過程中發現該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://stackoverflow.com/questions/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.
從開發者遇到問題後調試定位這個角度上說，還是ABAP On-Premises方便啊。
感謝閱讀。
要獲取更多Jerry的原創文章，請關注公衆號"汪子熙":
ABAP專題