换行符应包含在http响应内容长度中吗



发送HTTP响应时,我是否应该用换行符(行分隔符)结束响应主体(内容本身)?

如果是,我是否应该在内容长度中包括行分隔符的大小(如果发送,我想将计数增加2)?

发送HTTP响应时,我应该用换行符(行分隔符)结束响应主体(内容本身)吗?如果是,我是否应该在内容长度中包括行分隔符的大小(如果发送,我想将计数增加2)?

在HTTP响应的消息体中发送的资源数据可能包括自己的换行符(在文本文件等中很常见),但就HTTP本身而言,这是任意数据。消息数据中的换行符不是HTTP响应本身的一部分。HTTP响应通过到达Content-Length(这是资源数据的字节大小)而终止,除非使用Transfer-Encoding(在这种情况下,忽略Content-Length,使用chunked编码,这是自终止的),或者在响应结束时关闭连接。这在RFC 2616第4.4节:中有描述

4.4消息长度消息的传输长度是消息正文的长度它出现在消息中;也就是说,在任何传输编码已应用。当消息正文包含在消息中时该实体的传递长度由以下其中一项决定(按优先顺序):1.任何"不得"包含消息正文的响应消息(如作为1xx、204和304响应以及对HEAD的任何响应请求)总是由标头字段,与中存在的实体标头字段无关消息。2.如果存在传输编码报头字段(第14.41节),并且具有除"identity"以外的任何值,则传输长度为通过使用"分块"传输编码来定义(第3.6节),除非通过关闭连接来终止消息。3.如果存在Content-Length头字段(第14.13节),则其OCETs中的十进制值表示实体长度和传输长度。不得发送Content-Length标头字段如果这两个长度不同(即,如果传输编码标头字段存在)。如果收到的消息同时带有传输编码报头字段和内容长度报头字段,必须忽略后者。4.如果消息使用媒体类型"multipart/byteranges",并且未另行指定传输长度,则此self-定界介质类型定义传输长度。此媒体类型除非发件人知道收件人可以解析,否则不得使用它请求中存在具有多字节的Range标头-1.1客户端的范围说明符意味着客户端可以解析多部分/字节范围响应。范围标头可能由1.0代理转发,而该代理不转发了解多部分/字节范围;在这种情况下,服务器必须使用第1、3或5项中定义的方法对消息进行定界本节。5.通过服务器关闭连接。(关闭连接不能用于指示请求正文的结束,因为则服务器不可能发回响应。)为了与HTTP/1.0应用程序兼容,HTTP/1.1请求包含消息正文必须包含有效的Content-Length标头字段,除非已知服务器符合HTTP/1.1。如果请求包含消息主体,并且没有给出内容长度,如果不能,服务器应该以400(错误请求)响应确定消息的长度,或者如果它希望坚持接收有效的内容长度。所有接收实体的HTTP/1.1应用程序都必须接受"分块"传输编码(第3.6节),从而允许此机制在无法确定消息长度时用于消息提前消息不得同时包含Content-Length标头字段和非身份转移编码。如果消息中包含非-身份传输编码,内容长度必须被忽略。当在消息正文所在的消息中给定内容长度时允许,其字段值必须与消息正文。HTTP/1.1用户代理必须在接收并检测到无效长度

我在RFC 2616:中没有看到这样的东西

响应=状态行;第6.1节*(通用标题;第4.5节|响应标头;第6.2节|实体报头)CRLF);第7.1节CRLF[消息正文];第7.2节

响应中有两个换行符,都在标头的末尾,而不是消息正文的末尾。标题将描述如何终止消息正文。

发送HTTP响应时,我应该结束响应主体(内容本身)与换行符(行分隔符)?

RFC不要求您发送换行符。消息长度不是基于存在这样的换行符来计算的。请参阅"消息长度"部分,该部分介绍了如何计算消息长度。

最新更新