关于UPnP Device Architecture 2.0的阅读笔记（八）

设备描述之HTTP使用的一般要求

    所有设备和控制点的基本传输推荐使用HTTP/1.1兼容,至少是HTTP/1.0兼容.
    无论使用那个版本,其他所有必须的组件必须相应被实现.
    如果一个控制点使用HTTP/1.0绑定一个SOAP请求却没有设置KeepAlive符,设备将在响应之后关闭socket.若一个控制点使用HTTP/1.1绑定一个SOAP请求却设置了"Connection:CLOSE"符,设备将在响应之后关闭socket.

    USER-AGENT头信息

        控制点可以在任何UPNP相关的HTTP请求中加入USER-AGENT头信息标识自己支持UPNP1.1
        格式: USER-AGENT: OS/version UPnP/2.0 product/version    ##允许,由设备提供商指定
        具体如: USER-AGENT: unix/5.1 UPnP/2.0 MyProduct/1.0

    Accept-Encoding头信息

        控制点可以在任何UPNP相关的HTTP请求中加入Accept-Encoding头信息标识自己支持的编码类型
        格式: Accept-Encoding: compress,gzip  ##允许,由RFC2616 14.3节规范

    UPnP友好名头信息

        控制点应加入CPFN.UPNP.ORG来表示自己的友好名字
        格式: CPFN.UPNP.ORG: friendly name            ##必须

    UPNP标识符头信息

        表示控制点的UUID
        格式: CPUUID.UPNP.ORG: uuid of control point  ##允许
    服务商提供的或工作委员会定义的HTTP头信息
        格式: field-name: token"."domain-name
        domain-name可以是提供商域名或UPNP.ORG

    HTTP/1.0永久连接

        一些1.0标准的实现定义了所谓的永久连接.这个功能有很多用途。但这个功能不应该在任何UPnP设备或控制点实现。

    HTTP/1.0 HEAD请求

        一些实现使用HEAD请求来预先决定一个GET请求的内存需求。一些服务可能会不知道动态内容的大小。这种情况下，相应将不会包含CONTENT-LENGTH头信息。这样控制点将不会依赖这个被HEAD响应指定的头信息。

    HTTP状态码

        对于非法的请求，服务器应该返回合适的HTTP状态码。一个设备或控制点使用4xx状态码来指示一个请求或响应格式的错误。例如，一个客户端发出一个PUT请求，但服务器并没有实现该方法，就会返回一个“405 Method Not Allowed",其他的如400 Bad Request
    

    HTTP/1.1和HTTP1.0兼容性

        1.1的设备和控制点应该可以同1.0的设备或控制点协同工作。

    HOST头信息

        所有的请求信息必须包含。依靠这个信息来找到目标设备

    HTTP/1.1 EXPECT: 100-Continue

        服务器允许发送一个“100-Continue”HTTP状态码告知客户端，接收到的头信息已经被处理。
        如果一个客户端希望接收此状态码然后决定发送消息体，那么其在请求时要加上“EXPECT: 100-Continue”头信息
        客户端也要处理没发送EXPECT: 100-Continue却接收到100-Continue的情形

    HTTP/1.1 分块编码(Chunked Encoding)

        支持HTTP/1.1的设备或控制点的广播应该也要支持对于分块编码的消息的解码。
        

    HTTP/1.1 持久连接(Persistent Connection)

        持久连接是HTTP/1.1定义的一个默认行为。
        如果一个服务器响应中包含一个“CONNECTION: close”头信息，则在响应之后将关闭连接。

        如果一个客户端在请求中包含一个“CONNECTION: close”头信息，则服务器将在响应后关闭连接。