详解http报文(2)-web容器是如何解析http报文的

摘要

在详解http报文一文中,详细介绍了http报文的文本结构。那么作为服务端,web容器是如何解析http报文的呢?本文以jetty和undertow容器为例,来解析web容器是如何处理http报文的。

在前文中我们从概览中可以了解到,http报文其实就是一定规则的字符串,那么解析它们,就是解析字符串,看看是否满足http协议约定的规则。

jetty

以下代码都是jetty9.4.12版本

如何解析这么长的字符串呢,jetty是通过状态机来实现的。具体可以看下 org.eclipse.jetty.http.HttpParse

总共分成了21种状态,然后进行状态间的流转。在 parseNext 方法中分别对起始行 -> header -> body content分别解析

整体流程

整体有三条路径

  1. 开始 -> start-line -> header -> 结束

  2. 开始 -> start-line -> header -> content -> 结束

  3. 开始 -> start-line -> header -> chunk-content -> 结束 

起始行

start-line = request-line(请求起始行)/(响应起始行)status-line

  1. 请求报文解析状态迁移 请求行:START -> METHOD -> SPACE1 -> URI -> SPACE2 -> REQUEST_VERSION

  2. 响应报文解析状态迁移 响应行:START -> RESPONSE_VERSION -> SPACE1 -> STATUS -> SPACE2 -> REASON

header 头

HEADER 的状态只有一种了,在jetty的老版本中还区分了 HEADER_IN_NAM , HEADER_VALUE , HEADER_IN_VALUE 等,9.4中都去除了。为了提高匹配效率,jetty使用了Trie树快速匹配header头。

content

请求体:

  1. CONTENT -> END,这种是普通的带Content-Length头的报文,HttpParser一直运行CONTENT状态,直到最后ContentLength达到了指定的数量,则进入END状态

  2. chunked分块传输的数据 CHUNKED CONTENT -> CHUNK SIZE -> CHUNK -> CHUNK_END -> END

undertow

undertow是另一种web容器,它的处理方式与jetty有什么不同呢 状态机种类不一样了, io.undertow.util.HttpString.ParseState

具体处理流程在 HttpRequestParser 抽象类中

与jetty不同的是对content的处理,在header处理完以后,将数据放到 io.undertow.server.HttpServerExchange ,然后根据类型,有不同的content读取方式,比如处理固定长度的, FixedLengthStreamSourceConduit

关注公众号【方丈的寺院】,第一时间收到文章的更新,与方丈一起开始技术修行之路

我来评几句
登录后评论

已发表评论数()

相关站点

+订阅
热门文章