最近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://<host>: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://<host>: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方便啊。

感谢阅读。