企业官网建设流程全解析

适合谁收藏

• 正在实现 PLC 端 HTTP Server 的工程师。
• 正在排查监听、多连接、请求边界或响应发送问题的人。
• 需要建立 Server 真机验收清单的读者。

本篇位置服务器篇，第 4/7 篇；主系列第 08/28 篇。

现场问题

PLC 在线变量已经能看到完整请求行和 Header，但业务程序拿到的 Body 偶尔为空。这类故障往往只在网络抖动、Body 稍大或扫描周期较短时出现。

根因是把 Header 完整误判成消息完整。TCP 可以在任意字节位置分段，Header 和 Body 也不保证在一次 Read 中同时到达。

先给结论

Server 必须先找到 Header 结束位置，再解析消息边界字段，最后用实际接收字节数判断完整性。Parser 可以返回 NeedMoreData，但不能把半条请求交给业务。

读图重点

这张图只压缩本篇的判断路径。读图时先找“请求行”对应的输入边界，再沿着“当前只接受 chunked”检查状态怎样推进，最后用“与 Content-Length 同时出现时拒绝”确认输出是否已经形成验收证据。

把对象和边界分开

从协议约束到代码职责

协议约束

Server 必须先找到 Header 结束位置，再解析消息边界字段，最后用实际接收字节数判断完整性。Parser 可以返回 NeedMoreData，但不能把半条请求交给业务。 这条结论先限定消息什么时候成立，再限定哪个角色可以消费结果。若绕过协议边界直接驱动业务，半包、超时、重复执行和连接残留就会进入应用层。

工程抽象

解析器先保存原始 Header，再逐项查找 Host、Content-Type、Authorization、Transfer-Encoding、Content-Length 和 Connection。字段名按 ASCII 不区分大小写比较，但字段语法和重复次数仍然需要检查。

iNeedMoreData与iInvalidHeader不能混用。前者表示继续等待可能得到合法消息，后者表示继续等也不会变正确。这个差别直接决定连接是保留还是返回 400。

• 请求行：工程职责是“方法、目标、版本”。它不能只停留在命名层面，运行时必须能通过“格式非法立即拒绝”观察到输入、状态或结果；否则这一层即使有代码，也没有形成可验证边界。
• Host：工程职责是“HTTP/1.1 必需且只能一个”。它不能只停留在命名层面，运行时必须能通过“缺失或重复返回协议错误”观察到输入、状态或结果；否则这一层即使有代码，也没有形成可验证边界。
• Content-Length：工程职责是“声明普通 Body 长度”。它不能只停留在命名层面，运行时必须能通过“必须与实际字节数核对”观察到输入、状态或结果；否则这一层即使有代码，也没有形成可验证边界。
• Transfer-Encoding：工程职责是“当前只接受 chunked”。它不能只停留在命名层面，运行时必须能通过“与 Content-Length 同时出现时拒绝”观察到输入、状态或结果；否则这一层即使有代码，也没有形成可验证边界。

程序单元

本篇主证据来自FB_HttpMessageParser.st中以sHeaderName := 'Host'为定位点的连续源码。这里不是为了展示语法，而是把协议约束落到确定程序单元：输入先进入结构体或缓冲区，状态机只在本周期处理可确认的部分，长度和结束条件决定能否前进，错误码与指标负责把失败原因带出对象边界。这样一来，“Header 完整不等于请求完整。”可以在代码、在线变量和外部报文之间逐项对照，而不是依赖经验猜测。

本篇核心源码片段

下面两段代码来自同一个真实文件FB_HttpMessageParser.st，以sHeaderName := 'Host'为中心连续截取，没有改写变量、删除分支或用伪代码替代。第一段用于确认入口与前置条件，第二段用于确认状态、边界和输出。核对时重点看“方法、目标、版本”怎样进入对象，以及“与 Content-Length 同时出现时拒绝”怎样证明本次处理已经结束。若两段之间的连续关系无法解释“歧义边界必须拒绝，不能猜。”，就不能把局部代码截图当成实现证据。

片段一：入口、声明与前置条件

END_IF iHeaderStart := iFirstLineEnd + 2; iHeaderLen := iHeaderEnd - iHeaderStart; IF iHeaderLen > GVL_Http.cnMaxHeaderSize THEN M_SetError( eNewError := E_HttpError.iBufferTooSmall, sMessage := 'request header exceeds limit' ); RETURN; END_IF IF iHeaderLen > 0 THEN sHeaderText := MID(sMessage, iHeaderLen, iHeaderStart); ELSE sHeaderText := ''; END_IF stRequest.sRawHeaders := sHeaderText; bHeaderFound := F_HttpFindHeader( sHeaders := sHeaderText, sHeaderName := 'Host', sValue => sHeaderValue, uiCount => uiHeaderCount, bInvalidGrammar => bHeaderInvalid ); IF bHeaderInvalid THEN M_SetError( eNewError := E_HttpError.iInvalidHeader, sMessage := 'request header grammar is invalid' ); RETURN; ELSIF NOT bHeaderFound THEN M_SetError( eNewError := E_HttpError.iMissingHost, sMessage := 'request host is missing' ); RETURN; ELSIF uiHeaderCount > 1 THEN M_SetError( eNewError := E_HttpError.iDuplicateHost, sMessage := 'request host is duplicated' ); RETURN; ELSE stRequest.sHost := sHeaderValue; END_IF bHeaderFound := F_HttpFindHeader( sHeaders := sHeaderText, sHeaderName := 'Content-Type', sValue => sHeaderValue, uiCount => uiHeaderCount, bInvalidGrammar => bHeaderInvalid ); IF bHeaderFound THEN stRequest.sContentType := sHeaderValue; END_IF bHeaderFound := F_HttpFindHeader( sHeaders := sHeaderText, sHeaderName := 'Authorization', sValue => sHeaderValue,

这一段先回答对象在什么输入和状态下开始工作。阅读时要核对变量的初值、长度上限和启动条件，不能只看某个布尔量是否变成 TRUE。

片段二：状态推进、边界与输出

uiCount => uiHeaderCount, bInvalidGrammar => bHeaderInvalid ); IF bHeaderFound THEN stRequest.sAuthorization := sHeaderValue; END_IF stRequest.bTransferChunked := FALSE; bHeaderFound := F_HttpFindHeader( sHeaders := sHeaderText, sHeaderName := 'Transfer-Encoding', sValue => sHeaderValue, uiCount => uiHeaderCount, bInvalidGrammar => bHeaderInvalid ); IF uiHeaderCount > 1 THEN M_SetError( eNewError := E_HttpError.iUnsupportedTransferEncoding, sMessage := 'duplicate transfer-encoding' ); RETURN; END_IF IF bHeaderFound THEN IF F_HttpAsciiEqualsIgnoreCase( sLeft := sHeaderValue, sRight := 'chunked' ) THEN stRequest.bTransferChunked := TRUE; ELSE M_SetError( eNewError := E_HttpError.iUnsupportedTransferEncoding, sMessage := 'unsupported transfer-encoding' ); RETURN; END_IF END_IF stRequest.bHasContentLength := FALSE; bHeaderFound := F_HttpFindHeader( sHeaders := sHeaderText, sHeaderName := 'Content-Length', sValue => sHeaderValue, uiCount => uiHeaderCount, bInvalidGrammar => bHeaderInvalid ); IF uiHeaderCount > 1 THEN M_SetError( eNewError := E_HttpError.iInvalidContentLength, sMessage := 'duplicate content-length' ); RETURN; END_IF IF bHeaderFound THEN stRequest.bHasContentLength := TRUE; IF NOT F_HttpParseContentLength( sValue := sHeaderValue, udiValue => udiContentLength ) THEN M_SetError( eNewError := E_HttpError.iInvalidContentLength, sMessage := 'invalid content-length' ); RETURN;

第二段继续展示同一连续源码范围。把它与第一段合起来，才能判断输入怎样被锁存、状态何时推进、边界何时满足，以及错误出口是否保留了足够诊断信息。

验证路径

场景 1：Header 半包

先只发送请求行和一半 Header，不发送最终的空行。Parser 应停在继续接收或需要更多数据的状态，业务路由、响应构造和请求完成标志都不能动作；补上剩余 Header 与CRLF CRLF后，状态才允许进入 Header 解析完成。这个场景专门验证“Header 结束符”是否被当成硬边界。

场景 2：Body 晚到

发送带Content-Length: 20的 POST，但第一段只给 8 个字节 Body。此时请求对象可以保存 Header 信息，但不得把 Body 交给应用层；继续补齐剩余 12 个字节后，Content-Length、接收长度和最终 Body 必须一致。若 Header 刚收完就触发业务，PLC 端一定会遇到半包误执行。

场景 3：Host 异常

分别构造缺失 Host、重复 Host、Host 值为空三类请求。期望结果是同一个协议错误出口可以解释问题，诊断文本能指出 Host 相关原因，并且不会继续进入路由层。这样才能把“请求不合法”和“资源不存在”区分开。

场景 4：TE/CL 冲突

构造同时携带Transfer-Encoding: chunked和Content-Length的请求，或者重复声明同一边界字段。PLC 端应拒绝歧义输入，而不是随便选一个字段继续解析。通过口径是错误码、诊断文本和连接处理策略都明确指向边界冲突。

常见误判

• 找到$R$N$R$N就触发业务，Body 晚到时得到一条伪完整请求。
• 把缺少数据和语法非法都处理成继续等待，坏请求长期占用槽位。
• 忽略重复 Host 或 TE/CL 冲突，让状态机在歧义边界上自行猜测。

这些误判的共同点，是拿一个局部现象替代完整事务。定位时必须回到本篇的输入、状态、边界和输出四个坐标，并用相同输入完成回归。

这一篇你最该记住

• Header 完整不等于请求完整。
• NeedMoreData 是状态，不是错误兜底。
• 歧义边界必须拒绝，不能猜。

系列导航

• 系列：CodeSys HTTP 系列教程，第 08/28 篇。
• 阶段：服务器篇，职责线位置 4/7。
• 上一篇：第07篇
• 下一篇：第09篇
• 发布顺序：基础认知 -> Server -> Client -> 完整源码加更 -> 综合收束。