最近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理論上的差異解析，網上一搜一大把：

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

分幾種情況進行討論。

首先進行第一輪測試。

將這種來自SAP UI5標準庫檔案的url貼上到瀏覽器裡訪問：

~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：

~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專題