分类 Web 相关 下的文章

关于 http 1.1 的 Keep-Alive 的持久连接 以及客户端和服务器端的处理

关于 http 1.1 的 Keep-Alive 有以下几点要注意:

  1. default 行为
  2. 可设置timeout 和 max request 数: Keep-Alive: timeout=5, max=1000

对于Java 无论是BIO 还是NIO,客户端和服务端都可以采用一定的策略来关闭这个http 连接。另外TCP层有半连接概念,Http层没有,要么关掉,要么没关。

那么若是 Keep-Alive 的长连接, 如何区分一个 request payload 数据是不是已经结束呢?

server端:

以 tomcat8 为例: 在 tomcat8 的代码里面,
org.apache.coyote.http11.Http11Processor 的 prepareRequest() 方法里,
可以看到处理 HTTP header: transfer-encoding 的逻辑: 根据是 identity 或者 chunked
来使用不同的 filter 类来判断 payload 有没有结束, 所以在 servelet 的 service() 或 doPost
方法里, 拿到 inputStream 的时候, 已经不用担心 payload 结束的问题. 具体的 Filter 类在 package
org.apache.coyote.http11.filters里面, 比如 处理 input 的就有:
ChunkedInputFilter, IdentityInputFilter.

client 端

以 apache httpClient 5 为例: 因为 Client 端不像服务器端有过滤处理, 所以 client 端要自己处理,
所以在 httpClient 的代码里面, 就有专门处理 payload 是否结束的代码. 有个类:
DefaultContentLengthStrategy, 它有个方法 determineLength(final HttpMessage
message), 用来判断是使用 chunked 还是 content-length. 然后根据这个返回结果,
使用不同的解码器或者使用不同的 Stream 来封装 payload. stream 如:
org.apache.hc.core5.http.impl.io.ChunkedInputStream 和
org.apache.hc.core5.http.impl.io.IdentityInputStream; 解码器如:
org.apache.hc.core5.http.impl.nio.LengthDelimitedDecoder 和
org.apache.hc.core5.http.impl.nio.ChunkDecoder

关于 http 1.1 header Transfer-Encoding 的用法

关于 Transfer-Encoding 在官方文档中有以下几个点要注意:

  1. 它是 Hop to Hop 的 header, 也就是中间代理可以改的, 并不是 end to end 的 header;
  2. 它是传输编码, 并不是 content-encoding, content-encoding 是 end to end;
  3. 可能的值有: chunked, compress, deflate, gzip, identity. 可以是多个, 用逗号隔开;
  4. 如果是 chunked, 因为预先不知道内容长度, 所以 Content-Length 是不需要的;
  5. 如果有 chunked, chunked 必须在逗号隔开的最后一个;
  6. HTTP/1.1 应用程序必须能够编码/解码 chunked;
  7. identity 代表原样传输, 没有编码, 必须永远被接受;
  8. 在 request 的 header 中的 TE, 其实是 Accepted-Transfer-Encoding 的缩写;

比较容易混淆, 官方文档有没有说明的是:
尽管 Transfer-Encoding 是一个 response header, 可是在 request 的 header 中也可以使用这个 header, 并且服务端都能处理. 参考下面这 2 处文章:

If a Transfer-Encoding field with a value of "chunked" is specified in
an HTTP message (either a request sent by a client or the response
from the server)

Chunking is most often used by the server for responses, but clients
can also chunk large requests

另外在 Tomcat8 的实现中, org.apache.coyote.http11.Http11Processor 的类的 prepareRequest() 方法中, 我们可以看到具体的对于 Transfer-Encoding 的处理方法. 其中包含对于 request 使用 chunked 处理.

使用 Curl 测试 content-length 和 payload 的数据量不一致的问题:

curl -X POST http://localhost:8080/post --header "Content-Type:application/json" --header "content-length: 2" --header "transfer-encoding:abc" --data "{"

更多内容, 参考: rfc7230, RFC2616
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Transfer-Encoding

HSTS (HTTP Strict-Transport-Security) 笔记

HSTS 是 HTTP Strict-Transport-Security 的缩写,是浏览器的一个功能. 它告诉浏览器对于某些站点只能用 HTTPS 访问, 不能用 http.

使用 301 的危险: 每次都使用 301 重定向,hacker 还是在跳转之时有机会去截获信息或伪造某些页面的。

它通过服务器返回的 response 的 header 中的 Strict-Transport-Security 这一项来设置.
语法: Strict-Transport-Security: max-age=<expire-time>; includeSubDomains; preload.

当用户当前访问的是 HTTPS 站点,并且证书是合法有效的, 如果 response header 中包含 Strict-Transport-Security 做个 header, 那么浏览器就会知道: 这个站点在某个时间点之前都要使用 https 访问,如果用户输入 http 的协议, 自动转换为 https. 如果没到期, 后续的浏览又带来这个 header 会自动更新终止时间. 如果到期, 这个规则自动失效.

如果用户当前访问的是 http 站点, 并且这个站点之前还没有使用 HSTS, 那么浏览器会忽略这个 header, 因为没有使用 https, 这个回话可能会被拦截篡改.

当站点使用了 HSTS, 客户agent 会在过期日之前一直使用 https

参见: Strict-Transport-Security wiki

Unicode 字符集 和 UTF 编码

  1. Unicode 是字符集, 类似ASCII 码有127字符, Unicode 已经包含17个planes, 每个plane包含65536个代码点(code point)
  2. UTF 是Unicode字符集的编码, 就是Unicode 字符集在磁盘的表示, 参考这篇很不错的文章 十分钟搞清字符集和字符编码
  3. Windows 和 Java 默认使用 UTF-16, Web 默认使用 UTF-8
  4. UTF-8 兼容ASCII
  5. 非英文域名 即 IDNs 要使用 Punycode 去转. 尽管你的URL的域名部分是 新华网.中国 或 %E6%96%B0%E5%8D%8E%E7%BD%91.%E4%B8%AD%E5%9B%BD (encodeURI("新华网.中国")的结果) 在去到DNS 解析的时候, 都是翻译为 Punycode 去做DNS 查询的
  6. Unicode 要区分 字符, codepoint, UTF 编码后的值 如 : 田 的codepoint 是30000 (0x7530), UTF-8 编码后是: E794B0 (使用 encodeURI("田") 得到)

JavaScript 数字 字符 转换

  1. 数字进制转换
    (10).toString(8) //10进制到8进制

(077).toString() //8进制到10进制
(0x11).toString(8) //16进制到8进制
(0x11).toString(10) //16进制到10进制
(0x11).toString(2) //16进制到2进制
(0x11).toString(3) //16进制到3进制

3进制转换为16进制
parseInt("122", 3).toString(16); 先要转换为10进制, 然后再通过10进制转换为16进制

  1. 字符-数字 转换
    String.charCodeAt()

String.fromCharCode()
String.prototype.charAt()
String.fromCodePoint()
String.prototype.codePointAt()