Http的状态管理机制(cookie)

本文涉及的产品
.cn 域名,1个 12个月
简介:


HTTP状态管理机制

摘要

这篇文档是为HTTP request 和 response之间创建一个有状态的会话指明一个方法,并描述了两个头字段:Cookie和Set-cookie,用于携带服务端和客户端之间的状态信息。

术语

FQHN(fully-qualified host name):指的是主机的FQDN(fully-qualified domain name),比如以1级域名.com 或 .uk结尾的完全指定的域名,或者指主机的IP地址。(倾向于前者,后者不建议)

request-host:指的是客户端发出请求指向的服务器端的主机(跟端口无关),这里request-host是一个FQHN.

request-URI:指的是客户端发出请求指向的服务器端绝对路径部分。

host-name:指的是一个IP地址或者一个FQHN字符串。

domain-match:满足下面其中一种情况则A的host-name domain-match B的host-name:

  • 两者的host-name都是IP并完全一致
  • 两者的host-name都是FQDN字符串且完全一致
  • A的host-name是FQDN字符串并且格式为NB,其中N是一个非空字符串,B个格式是.C,而C是一个FQDN字符串。也就是说A = N.C,B = .C的情况。比如:域x.y.com就domain-match 域.y.com,而域x.y.com就不domain-match 域y.com。(这个定义对是否能使用某个域的cookie非常关键)同时要注意,A domain-match B,不能说明B domain-math A,同样需要通过这个定义来判断。

语法

Set-cookie 和 Cookie这两个头字段有相似的语法。

(Set-cookie/Cookie) = av-pair *(";" av-pair)

其中:

av-pair = attr ["=" value]

attr = token

value = word

word = token | quoted-string(带引号的字符串)

这里边,token的定义得去查看HTTP/1.1 specification [RFC 2068] 。等号左右允许有空格。

服务器端

为了与客户端之间的会话保持状态信息,服务器端在response头中使用Set-Cookie字段,而客户端如果想保持状态信息,得在request头中加Cookie字段。服务器端若要终止这个会话,可以简单的设置Set-Cookie为Max-Age=0。

服务器端可能会包含多个Set-cookie字段,不过网关会把这些合并成一个Set-cookie字段,用逗号,分隔。

Set-Cookie

set-cookie = "Set-Cookie:" cookies

其中

cookies = 1#cookie

cookie = NAME "=" VALUE *(";" cookie-av)

NAME = attr

VALUE = value

cookie-av = "Comment" "=" value | "Domain" "=" value | "Max-Age" "=" value | "Path" "=" value | "Secure" | "Version" "=" 1*DIGIT

NAME=VALUE:必须的,虽然VALUE严格上来说对客户端是不透明的,然实际上通过检查Set-Cookie字段还是可以读到的。

Comment=comment:可选,描述该Cookie的用处。

Domain=domain:可选,指定了cookie有效的域。明确指定的domain必须以.开头。

Max-Age=delta-seconds:可选,指cookie的存活时间,以秒为单位,非负数。Max-Age=0表示客户端需要立即丢弃该cookie。

Path=path:可选,指在某URL的子路径下cookie有效。

Secure:可选,(翻者注:有点难理解)查阅资料解释如下:创建的 Cookie 会被以安全的形式向服务器传输,也就是只能在 HTTPS 连接中被浏览器传递到服务器端进行会话验证,如果是 HTTP 连接则不会传递该信息,所以不会被窃取到Cookie 的具体内容。

HTTP状态管理机制 2011 补充

HttpOnly:可选,用于告诉客户端不能通过”non-HTTP“的方式获取cookie(比如浏览器的API:document.cookie)。

Version=version:必须。十进制的整数,指状态管理中cookie指向的版本。

控制缓存

如果cookie只给某一用户使用,则Set-Cookie头不能被缓存,相反则应该缓存。

根据情况,服务器端应该在response头中添加一些字段:

  • 禁止缓存Set-Cookie头,则:Cache-control:no-cache="set-cookie"。
  • 禁止在共享缓存中缓存私密文档:Cache-control:private。
  • To allow caching of a document, but to require that proxy caches (not user agent caches) validate it before returning it to the client:Cache-control:proxy-revalidata。(译者注:这条跟下面一条区别在哪里没看出)
  • To allow caching of a document and request that it be validated before returning it to the client (by "pre-expiring" it): Cache-control:max-age=0

HTTP/1.1服务器如果不确定下游是否有代理,则必须设置Expires: old-date。(译者注:防止cookie被代理缓存,会产生bug)。Cache-Control指令会覆盖Expires:old-date。

客户端

客户端在接收到Set-Cookie的response头之后,会对其中可选的属性应用默认值:

  • Version:根据Netscape规范。
  • Domain:默认为request-host(不是以.开头)(译者注:服务器端有时候会不设置这个Domain,以为到了客户端之后会设置成客户端的域名,其实是目标服务器的域名)。
  • Max-Age:默认行为是如果客户端存在这个cookie,那这个cookie会被清除掉。
  • Path:请求URL中的path,不右边最右边的'/'。
  • Secure:客户端将通过一条不安全的通道发送cookie(译者注:也就是Http)。

拒绝cookie

考虑安全,如果满足下面的情况,客户端将不会保存cookie:

  • Path不是request-URI的前缀。
  • Domain的值不是以.开头或者没有内含的点(eg: .com没有,segmentfault.com有)。
  • request-host不 domain-match Domain的值。
  • request-host是个FQDN并且格式为HD,其中D是Domain的值,H是一个包含.的字符串。

    举例子:

  • request-host = x.foo.com,Domain = .foo.com 通过。
  • Domain=.com 或者 Domain=.com. 不通过,因为没有内含的点.。
  • Domain=ajax.com 不通过,因为没有以.开头。

Cookie 管理

如果Set-Cookie中的cookie名字已经存在在客户端里,并且Domain和Path都一样,那么新的Cookie会覆盖旧的;如果新的Cookie中Max-Age=0,那么新旧cookie都会被清除掉。

由于客户端存储cookie的空间有限,所以可能会应用如LRU等算法来清除旧的cookie。

发送Cookie到服务器端

基于下面几种,客户端会在发送请求到服务器端的时候将cookie包含在request头中。

  • request-host
  • request-URI
  • cookie的存活时间

Cookie头的语法:

cookie = "Cookie:" cookie-version 1*((","|";") cookie-value)

其中:

cookie-value = NAME "=" VALUE";" path

cookie-version = "$Version" "=" value

NAME = attr

VALUE = value

path = "$Path" "=" value

domain = "$Domain" "=" value

同时以上属性的值有这样的要求:如果有相应的Set-Cookie response头,则cookie-version的值应该与此response中的cookie-version一致,否则为0.同理path也需一致,否则该属性会被剔除掉。同理Domain的值也需一致,否则也会被剔除掉。

请求头中可以包含哪些cookie有以下规则:

  • Domain:服务器端的FQHN必须domain-match Domain的值。
  • Path:Path的值必须是request-URI的前缀。
  • Max-Age:不能是已经过期了。

缓存代理服务器

缓存代理服务器必须遵循下面规范:

  • 依据缓存验证规则。
  • 将response头(包含Set-cookie)传递到客户端。
  • 将request头(包含Cookie)传递给服务器端。
作者:zhoushx3
来源:51CTO
相关文章
|
5月前
|
存储 缓存 安全
第二章 HTTP请求方法、状态码详解与缓存机制解析
第二章 HTTP请求方法、状态码详解与缓存机制解析
|
5月前
|
存储 缓存 前端开发
HTTP的缓存机制是什么?
HTTP的缓存机制是什么?
68 1
|
2月前
|
存储 JavaScript 前端开发
Cookie 反制策略详解:Cookie加解密原理、Cookie和Session机制、Cookie hook、acw_sc__v2、jsl Cookie调试、重定向Cookie
Cookie 反制策略详解:Cookie加解密原理、Cookie和Session机制、Cookie hook、acw_sc__v2、jsl Cookie调试、重定向Cookie
72 1
|
2月前
|
存储 安全 搜索推荐
HTTP的Cookie机制
【8月更文挑战第19天】Cookie 是服务器为识别用户身份而发送给浏览器的小型文本文件。首次访问时,服务器通过响应中的 Set-Cookie 创建并发送 Cookie 给浏览器。
|
3月前
|
消息中间件 API 数据库
在微服务架构中,每个服务通常都是一个独立运行、独立部署、独立扩展的组件,它们之间通过轻量级的通信机制(如HTTP/RESTful API、gRPC等)进行通信。
在微服务架构中,每个服务通常都是一个独立运行、独立部署、独立扩展的组件,它们之间通过轻量级的通信机制(如HTTP/RESTful API、gRPC等)进行通信。
|
3月前
|
网络协议 Python
Python实现HTTP 传输的断点续传机制
使用Python `requests`库实现HTTP断点续传下载大文件,通过设置`Range`头部从上次中断的位置开始继续下载。示例代码展示了一个名为`resume_download`的函数,它接收URL、文件名和最后字节位置参数,以追加方式打开文件并逐块写入内容。要启用HTTP长连接,可添加`Connection: keep-alive`到请求头。
106 0
|
5月前
|
存储 安全 Java
基于 Cookie 的信息共享机制
基于Cookie的信息共享机制用于客户端状态保持。Cookie是服务器生成并发送到浏览器的文本文件,存储用户状态和安全信息。当用户发起请求时,浏览器会将Cookie一并发送,服务器据此处理。Cookie分为内存和硬盘两种,有持久和非持久之分,但因以明文存储,存在安全隐患。JSP/Servlet中的Cookie类提供管理方法。示例代码展示了如何使用JSP设置和检查Cookie。需注意Cookie的安全问题,避免数据泄露。
57 3
|
5月前
|
存储 缓存 前端开发
http缓存机制
HTTP缓存机制通过缓存控制头、实体标签和最后修改时间头优化Web性能,减少网络请求。Cache-Control指令如`public`, `private`, `max-age`, `no-cache`, `no-store`管理缓存行为。ETag用于验证资源完整性,Last-Modified检查资源是否更新。前端可利用Web存储和服务工作者进行细粒度缓存控制。正确配置缓存关键在于适应应用场景和需求。
|
5月前
|
存储 安全 Java
cookie机制 + java 案例
cookie机制 + java 案例
38 0
|
5月前
|
存储 缓存 数据安全/隐私保护
HTTP之Session、Cookie 与 Application
HTTP之Session、Cookie 与 Application
74 0

热门文章

最新文章

下一篇
无影云桌面