transferEncoding

HTTP的请求报文结构和响应报文结构 HTTP请求报文 主要由请求行、请求头、空行、请求正文（Get请求没有请求正文）4部分组成。 1、请求行 　　由三部分组成，分别为：请求方法、URL以及协议版本，之间由空格分隔； 　　请求方法包括GET、HEAD、PUT、POET、TRACE、OPTIONS、DELETE以及扩展方法，当然并不是所有的服务器都实现了所有的方法，部分方法即便支持，出于安全性的考虑也是不同的； 　　协议版本的格式为：HTTP/主版本号.次版本号，常用的有HTTP/1.0和HTTP/1.1； 2、请求头 　　请求头部为请求报文添加了一些附加信息，由“名/值”对组成，每行一对，名和值之间使用冒号分隔。 　　常见请求头如下： 3、空行 　　请求头的最后会有一个空行，表示请求头部结束，接下来为请求正文，这一行非常重要，必不可少。 4、请求正文 　　可选部分，比如GET请求就没有请求正文。 HTTP响应报文 主要由状态行、响应头、空行、响应正文4部分组成。 1、状态行 　　由3部分组成，分别为：协议版本、状态码、状态码描述，之间由空格分隔； 2、响应头 　　与请求头类似，为响应报文添加一些附加信息。 　　常见响应头如下： 3、空行 4、响应正文 常见HTTP首部字段 A、通用首部字段（请求报文与响应报文都会使用的首部字段 ） 　　Date：创建报文时间 　

HTTP的请求报文结构和响应报文结构 HTTP请求报文 主要由请求行、请求头、空行、请求正文（Get请求没有请求正文）4部分组成。 1、请求行 　　由三部分组成，分别为：请求方法、URL以及协议版本，之间由空格分隔； 　　请求方法包括GET、HEAD、PUT、POET、TRACE、OPTIONS、DELETE以及扩展方法，当然并不是所有的服务器都实现了所有的方法，部分方法即便支持，出于安全性的考虑也是不同的； 　　协议版本的格式为：HTTP/主版本号.次版本号，常用的有HTTP/1.0和HTTP/1.1； 2、请求头 　　请求头部为请求报文添加了一些附加信息，由“名/值”对组成，每行一对，名和值之间使用冒号分隔。 　　常见请求头如下： 3、空行 　　请求头的最后会有一个空行，表示请求头部结束，接下来为请求正文，这一行非常重要，必不可少。 4、请求正文 　　可选部分，比如GET请求就没有请求正文。 HTTP响应报文 主要由状态行、响应头、空行、响应正文4部分组成。 1、状态行 　　由3部分组成，分别为：协议版本、状态码、状态码描述，之间由空格分隔； 2、响应头 　　与请求头类似，为响应报文添加一些附加信息。 　　常见响应头如下： 3、空行 4、响应正文 常见HTTP首部字段 A、通用首部字段（请求报文与响应报文都会使用的首部字段 ） 　　Date：创建报文时间 　

场景 网络访问关系图如下, PC浏览器需要访问到Tomcat的Web应用. 因为网络隔离, PC机所在的环境访问不了Nginx2, 所以加了一层Nginx1的网络代理. Ngnix1的简要配置如下: server{ listen 8888; server_name 10.254.209.65; location / { proxy_pass http://10.254.213.149:80; } } 然后Nginx2代理了tomcat应用, 简要配置如下: upstream tom { server ip:port; } server { listen 80; server_name 10.254.213.149; location /admin { proxy_pass http://tom/admin; } } 问题 在PC浏览器上输入 10.254.209.65:8888/admin/ 就可以正常显示tomcat的web页面, 而输入 10.254.209.65:8888/admin 时就404, 后者比前者少了一个斜杠“/”而已. 排查 在PC浏览器输入 10.254.209.65:8888/admin 时, 发现地址会莫名其妙地重定向为 10.254.209.65/admin/ 重定向之后的地址有2处明显变化: 一是端口8888变成了80(默认不显示) ;

序 本文主要研究一下jvm的CompressedClassSpace CompressedClassSpace java8移除了permanent generation，然后class metadata存储在native memory中，其大小默认是不受限的，可以通过-XX:MaxMetaspaceSize来限制 如果开启了-XX:+UseCompressedOops及-XX:+UseCompressedClassesPointers( 默认是开启 )，则UseCompressedOops会使用32-bit的offset来代表java object的引用，而UseCompressedClassPointers则使用32-bit的offset来代表64-bit进程中的class pointer；可以使用CompressedClassSpaceSize来设置这块的空间大小 如果开启了指针压缩，则CompressedClassSpace分配在MaxMetaspaceSize里头，即MaxMetaspaceSize=Compressed Class Space Size + Metaspace area (excluding the Compressed Class Space) Size 查看CompressedClassSpace大小 jcmd pid GC.heap_info / #

使用及对比 在 Startup.cs 中添加服务并使用即可,主代码如下: // Startup.cs public void ConfigureServices(IServiceCollection services) { // ... services.AddResponseCompression(); // ... } public void Configure(IApplicationBuilder app, IHostingEnvironment env) { // ... app.UseResponseCompression(); // ... } 未使用响应压缩中间件 新建一个 ASP.NET Core API 项目 运行并访问 响应头信息如下: Content-Type: application/json; charset=utf-8 Date: Fri, 06 Jul 2018 13:17:32 GMT Server: Kestrel Transfer-Encoding: chunked 使用响应压缩中间件 新建一个 ASP.NET Core API 项目 添加并配置 Microsoft.AspNetCore.ResponseCompression 响应压缩中间件 运行并访问 响应头信息如下: # gzip 压缩编码 Content-Encoding: gzip

HTTP权威指南笔记 第一部分、基本组成 一、HTTP报文 1.报文格式 报文的起始行和首部是以行分隔的，以回车换行CRLF进行结束。回车符ASCII码13，换行符ASCII码10. 请求报文格式 <method><request-URL><version> <headers> <entity-body> 响应报文格式 <version><status><reason-phrase> <headers> <entity-body> 2.HTTP方法 1)GET和HEAD被认为是安全方法 2)HEAD与GET方法的行为类似，但服务器在响应中只返回首部，不返回实体的主体部分。 HEAD可以用于判断资源类型，查看响应状态码(404是否存在等)，资源是否被修改等。 3)PUT方法与GET相反，用于向服务器写入文档。让服务器用请求的主体部分创建一个由所请求的 URL命名的新文档。 4)POST用于向服务器输入数据，如表单数据。 5)TRACE请求，主要用于诊断网络，可以查看代理和其他应用程序对用户请求所产生的修改。 6)OPTIONS方法用于请求服务器支持哪些方法 7)DELETE方法，请求服务器删除所请求的资源。 3.HTTP首部 包括通用首部(客户端和服务器端都可以使用)、请求首部、响应首部、实体首部、扩展首部 1)通用信息首部 Connection 允许客户端和服务器指定与请求

需求：我在Marketing Cloud的contact模型上用custom field这个应用创建了一个Extension field，名称为微信ID。 现在客户的需求是使用这个字段作为过滤条件进行搜索。 首先在界面上执行一次搜索，在Chrome开发者工具network标签里将这次搜索中前端发给后台的HTTP请求明细记录下来： 然后在postman里照样维护一份： payload: --batch_bd03-9977-8095 Content-Type: application/http Content-Transfer-Encoding: binary GET InteractionContacts?sap-client=100&$skip=0&$top=15&$filter=YY1_WECHATID_MPS%20eq%20%27i042410%27&$select=ImageURL%2cName%2cContactLevelName%2cCountryName%2cCity%2cEMailAddress%2cPhoneNumber%2cMobilePhoneNumber%2cCorporateAccountName%2cInteractionContactUUID%2cRelationship%2cType&$inlinecount=allpages HTTP/1.1 sap

今天解决了一个设置下载文件名为中文的问题：直接在Content-Disposition中设置中文会导致乱码。按照网上的办法（Content-Disposition + UTF-8）就搞定了。不过为了能搞清楚问题的关键所在，我还是去看了下官方文档，了解了下Content-Disposition的字段与意义。使用Content-Disposition可以设置文件名，但是要设置中文就需要进行编码，而RFC 822规定Message只能为ASCII，这就是问题所在。 Content-Disposition的定义 Hypertext Transfer Protocol – HTTP/1.1中的描述 Content-Disposition is not part of the HTTP standard, but since it is widely implemented, we are documenting its use and risks for implementors. The Content-Disposition response-header field has been proposed as a means for the origin server to suggest a default filename if the user requests that the

网站上线前需要对网站进行渗透测试，上一节我们Sine安全讲师讲了web的基础知识了解,明白了具体web运行的基础和环境和协议,这一节我们来讨论下域名和DNS工作原理以及http状态码和请求的协议来分析检测中的重点域名收集。 1.3. 域名系统 1.3.1. 域名系统工作原理 DNS解析过程是递归查询的，具体过程如下： 用户要访问域名www.xxxxx.com时，先查看本机hosts是否有记录或者本机是否有DNS缓存，如果有，直接返回结果，否则向递归服务器查询该域名的IP地址 递归缓存为空时，首先向根服务器查询com顶级域的IP地址 根服务器告知递归服务器com顶级域名服务器的IP地址 递归向com顶级域名服务器查询负责xxxxx.com的权威服务器的IP com顶级域名服务器返回相应的IP地址 递归向xxxxx.com的权威服务器查询www.xxxxx.com的地址记录 权威服务器告知www.xxxxx.com的地址记录 递归服务器将查询结果返回客户端 1.3.2. 根服务器 根服务器是DNS的核心，负责互联网顶级域名的解析，用于维护域的权威信息，并将DNS查询引导到相应的域名服务器。 根服务器在域名树中代表最顶级的 . 域， 一般省略。 13台IPv4根服务器的域名标号为a到m，即a.xxxxx.com到m.xxxxx.com，所有服务器存储的数据相同

作者 | 阿里云售后技术专家 声东 导读 ：当我们尝试去理解 K8s 集群工作原理的时候，控制器（Controller）肯定是一个难点。这是因为控制器有很多，具体实现大相径庭；且控制器的实现用到了一些较为晦涩的机制，不易理解。但是，我们又不能绕过控制器，因为它是集群的“大脑”。今天这篇文章，作者通过分析一个简易冰箱的设计过程，来帮助读者深入理解集群控制器的产生，功能以及实现方法。 K8s 集群核心组件大图 下图是 K8s 集群的核心组件，包括数据库 etcd，调度器 Scheduler，集群入口 API Server，控制器 Controller，服务代理 kube-proxy 以及直接管理具体业务容器的 kubelet。 这些组件逻辑上可以被分为三个部分： 核心组件 etc 数据库； 对 etcd 进行直接操作的入口组件 API Server； 其他组件, 这里的“其他组件”之所以可以被划分为一类，是因为它们都可以被看做是集群的控制器。 今天我们要讲的就是集群控制器原理。 控制器原理 虽然控制器是 K8s 集群中比较复杂的组件，但控制器本身对我们来说并不陌生的。我们每天使用的洗衣机、冰箱、空调等，都是依靠控制器才能正常工作。在控制器原理这一节，我们通过思考一个简易冰箱的设计过程，来理解 K8s 集群控制器的原理。 简易的冰箱 这个冰箱包括五个组件：箱体、制冷系统、照明系统