分类 Web 相关 下的文章

关于 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 处文章:

  • 在 Wiki https://en.wikipedia.org/wiki/Chunked_transfer_encoding 中的 Format 一节中, 有写到:

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)

  • 在 http://www.oracle.com/technetwork/systems/chunking-155634.html 中的写到:

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.

它通过服务器返回的 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, 这个回话可能会被拦截篡改.

参见: 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进制

  2. 字符-数字 转换
    String.charCodeAt()
    String.fromCharCode()
    String.prototype.charAt()
    String.fromCodePoint()
    String.prototype.codePointAt()

浏览器 同源策略

  1. 3个关键点 scheme, host, port in URL. IE 浏览器有一点点特殊: https://en.wikipedia.org/wiki/Same-origin_policy
  2. Same Origin Policy 只是禁止读取返回的信息, 并不禁止发送请求, 所以其实请求已发出,浏览器以及收到,只是发现不符合这个策略而终止. prelight 可以通过2步, 来避免发出真正的请求. 也就是有的文档提到的 禁止读, 不禁止写.
  3. 正因为不禁止发出请求, 所以同源策略不能阻止 CSRF 和 clickjacking;
  4. 尽管有同源策略,不同的网站还是可以通过link 相互关联, 跨站使用img, CSS, Javascript, 常见适用同源策略的是AJAX 请求,iframe 等;
  5. 尽管通过同源策略限制了 AJAX, 但是有些时候要需要跨站资源共享, 所以就有了 CSRS (Cross Site Resource Sharing)相关的http header;
  6. 同源策略的内容
  7. IE 浏览器的特殊之处: a: trust zone 里面的可以任意跨域, b: 端口号 不用来区分跨域. 这些都是非标准
  8. 可以通过 document.domain="company.com" 来让多个子domain之间或子domain 与父domain 之间实现跨域(同时端口号被设置为null);
  9. 如何绕过同源策略 详细文档
  10. CSRS
  11. JSONP
  12. window.postMessage Cross-document messaging
  13. 同一个主域下如果协议和端口一样, 可以通过设置 window.domain 来处理(只能从长到短)
  14. WebSocket
  15. window.name 传递
  16. 如何避免跨站写?
  17. CSRF token
  18. 如何防止跨站读?
  19. 使你的资源不可被嵌入(img, CSS, JavaScript): 更改资源 Content-Type, 使用动态CSRF token;
  20. 跨站的请求不能定制 HTTP header, 不跨站的则可以.