RFC2616中文版(7)实体(Entity)
2011-05-31 14:19
405 查看
7 实体(Entity)
如果不被请求的方法或响应的状态码所限制,请求和响应消息都可以传输实体。 实体包括实体头域(entity-header)与实体主体(entity-body),而有些响应只包括实体头域(entity-header)。
在本节中的发送者和接收者是否是客户端或服务器,这依赖于谁发送或谁接收此实体。
7.1 实体报文域(Entity Header Fields)
实体(entity-header)头域定义了关于实体主体的的元信息,或在无主体的情况下定义了请求的资源的元信息。有些元信息是可选的;一些是必须的。
entity-header = Allow ; Section 14.7
| Content-Encoding ; Section 14.11
| Content-Language ; Section 14.12
| Content-Length ; Section 14.13
| Content-Location ; Section 14.14
| Content-MD5 ; Section 14.15
| Content-Range ; Section 14.16
| Content-Type ; Section 14.17
| Expires ; Section 14.21
| Last-Modified ; Section 14.29
| extension-header
extension-header = message-header
扩展头机制允许在不改变协议的前提下定义额外的实体头域,但不保证这些域在接收端能够被识别。未被识别的头域应当被接收者忽略,且必须被透明代理(transparent proxy)转发。
7.2 实体主体(Entity Body)
由HTTP请求或响应发送的实体主体(如果存在的话)的格式与编码方式应由实体的头域决定。
Entity-body= *OCTET
如4。3节所述,实体主体(entity-body)只有当消息主体存在时时才存在。实体主体(entity-body)从消息主体通过传输译码头域(Transfer-Encoding)译码得到,传输译码用于确保消息的安全和合适的传输。
7.2.1类型(Type)
当消息包含实体主体(entity-body)时,主体的数据类型由实体头域Content-Type和Content-Encoding决定。这些头域定义了两层的顺序的编码模型:
Entity-body:=Content-Encoding( Content-Type( data) )
Content-Type指定了下层数据的媒体类型。Content-Encoding可能被用来指定附加的应用于数据的内容编码,经常用于数据压缩的目的,内容编码是请求资源的属性。没有缺省的译码。
任一包含了实体主体的HTTP/1.1消息都应包括Content-Type头域以定义实体主体的媒体类型。如果并且只有媒体类型没有通过 Content-Type头域指定时,接收者可能会尝试猜测媒体类型,这通过观察实体主体的内容并且/或者通过观察URI指定资源的扩展名。如果媒体类型 仍然不知道,接收者应该把类型看作”application/octec-stream”。
7.2.2实体主体长度(Entity Length)
消息的实体主体长度指的是消息主体在被应用于传输编码(transfer-coding)之前的长度。4.4节定义了怎样去确定消息主体的传输长度。
如果不被请求的方法或响应的状态码所限制,请求和响应消息都可以传输实体。 实体包括实体头域(entity-header)与实体主体(entity-body),而有些响应只包括实体头域(entity-header)。
在本节中的发送者和接收者是否是客户端或服务器,这依赖于谁发送或谁接收此实体。
7.1 实体报文域(Entity Header Fields)
实体(entity-header)头域定义了关于实体主体的的元信息,或在无主体的情况下定义了请求的资源的元信息。有些元信息是可选的;一些是必须的。
entity-header = Allow ; Section 14.7
| Content-Encoding ; Section 14.11
| Content-Language ; Section 14.12
| Content-Length ; Section 14.13
| Content-Location ; Section 14.14
| Content-MD5 ; Section 14.15
| Content-Range ; Section 14.16
| Content-Type ; Section 14.17
| Expires ; Section 14.21
| Last-Modified ; Section 14.29
| extension-header
extension-header = message-header
扩展头机制允许在不改变协议的前提下定义额外的实体头域,但不保证这些域在接收端能够被识别。未被识别的头域应当被接收者忽略,且必须被透明代理(transparent proxy)转发。
7.2 实体主体(Entity Body)
由HTTP请求或响应发送的实体主体(如果存在的话)的格式与编码方式应由实体的头域决定。
Entity-body= *OCTET
如4。3节所述,实体主体(entity-body)只有当消息主体存在时时才存在。实体主体(entity-body)从消息主体通过传输译码头域(Transfer-Encoding)译码得到,传输译码用于确保消息的安全和合适的传输。
7.2.1类型(Type)
当消息包含实体主体(entity-body)时,主体的数据类型由实体头域Content-Type和Content-Encoding决定。这些头域定义了两层的顺序的编码模型:
Entity-body:=Content-Encoding( Content-Type( data) )
Content-Type指定了下层数据的媒体类型。Content-Encoding可能被用来指定附加的应用于数据的内容编码,经常用于数据压缩的目的,内容编码是请求资源的属性。没有缺省的译码。
任一包含了实体主体的HTTP/1.1消息都应包括Content-Type头域以定义实体主体的媒体类型。如果并且只有媒体类型没有通过 Content-Type头域指定时,接收者可能会尝试猜测媒体类型,这通过观察实体主体的内容并且/或者通过观察URI指定资源的扩展名。如果媒体类型 仍然不知道,接收者应该把类型看作”application/octec-stream”。
7.2.2实体主体长度(Entity Length)
消息的实体主体长度指的是消息主体在被应用于传输编码(transfer-coding)之前的长度。4.4节定义了怎样去确定消息主体的传输长度。
相关文章推荐
- ADO.NET Entity Data Model 映射实体 视图
- 一个实体对象不能由多个 IEntityChangeTracker 实例引用
- [Programming Entity Framework] 第1章 ADO.NET实体框架介绍(一)
- 把 HTML 实体转换为字符:html_entity_decode() 函数
- 显示EF实体对象的详细错误信息 db.Entry(entity).GetValidationResult() 或 catch (DbEntityValidationException ex)
- Entityframework core 动态添加模型实体
- DiscuzNT 实体项目(Entity) 简析
- html_entity_decode() 将 HTML 实体转成字符原型
- DiscuzNT 实体项目(Entity) 简析
- Flex AS3与 ADO.NET Entity Framework 实体对象数据类型转换(转)
- 使用Stanford Word Segmenter and Stanford Named Entity Recognizer (NER)实现中文命名实体识
- 对一个或多个实体的验证失败。有关详细信息,请参阅“EntityValidationErrors”属性。
- EF4.1: Add/Attach and Entity States(EF中的实体状态转换说明)
- ADO.NET Entity Framework创建 Course Manager 应用程序(实体框架快速入门)
- ADO.NET Entity Framework如何:定义单个实体映射到两个表的模型
- ADO.NET Entity Framework 定义高级数据模型(实体框架任务)
- 设计模式学习—组合实体模式(Composite Entity Design Pattern)
- 对一个或多个实体的验证失败。有关详细信息,请参见“EntityValidationErrors”属性。
- C#综合揭秘——利用泛型与反射更新实体(ADO.NET Entity Framework)
- 提交验证操作失败。请检查 Entity.ValidationErrors 的 EntitiesInError 中的每个实体的详细信息