HTTP请求报头详解

合集下载

HTTP协议中的请求头和响应头

HTTP协议中的请求头和响应头

HTTP协议中的请求头和响应头HTTP协议是互联网中最重要的协议之一,它是实现Web服务的基础。

在HTTP通信过程中,客户端与服务器之间需要交换大量的信息,而其中的请求头和响应头则是最重要的两个部分。

本文将针对HTTP协议中的请求头和响应头进行详细介绍,探究其基本原理、常见类型以及使用方法,帮助读者更好地理解HTTP 协议。

HTTP请求头HTTP请求头通常包含以下内容:1. 请求的方法: HTTP协议规定了几种请求方法,包括GET、POST、PUT、DELETE等。

客户端在发送请求时需要指定请求方法,服务器接收到请求后便根据不同的方法处理请求。

2. 请求的URL:请求的URL通常指明了客户端请求数据的地址,包括主机名、端口号、路径等。

客户端通常通过浏览器输入URL来发起HTTP请求。

3. 请求的HTTP版本: HTTP标准目前有1.0和1.1两个版本,通常请求头中会包含HTTP版本信息。

4. 请求头部字段:请求头中可以包含多个字段,用于提供额外的请求信息,例如用户代理、接受的编码方式等。

5. 请求正文:请求体中包含了客户端向服务器传递的数据,通常用于提交表单数据或上传文件等操作。

HTTP响应头HTTP响应头通常包含以下内容:1. HTTP版本:响应头中会包含HTTP版本信息,以便客户端与服务器进行协议匹配。

2. 状态码: HTTP响应中的状态码用于表明服务器对请求的处理结果。

常见的状态码包括200表示成功、404表示未找到资源、500表示服务器内部错误等。

3. 响应头部字段:响应头中可以包含多个字段,用于提供响应信息,例如数据内容类型、服务器软件等。

4. 响应体:响应体中包含了由服务器返回给客户端的数据,可以是HTML页面、图片、视频等内容。

常见的请求头与响应头1. User-Agent:请求头中的User-Agent字段用于标明客户端浏览器的代理信息,例如Chrome、Safari等。

服务器可以利用该字段进行浏览器兼容性检测、广告投放等操作。

HTTP请求组成

HTTP请求组成

HTTP请求组成http请求由三部分组成,分别是:请求⾏、消息报头、请求正⽂。

请求⾏格式:Method Request-URI HTTP-Version CRLFMethod表⽰请求⽅法代码Request-URI是⼀个统⼀资源标识符HTTP-Version表⽰请求的HTTP协议版本CRLF表⽰回车和换⾏(除了作为结尾的CRLF外,不允许出现单独的CR或LF字符)。

常见的请求GET 请求获取Request-URI所标识的资源POST 在Request-URI所标识的资源后附加新的数据HEAD 请求获取由Request-URI所标识的资源的响应消息报头PUT 请求服务器存储⼀个资源,并⽤Request-URI作为其标识DELETE 请求服务器删除Request-URI所标识的资源OPTIONS 请求查询服务器的性能,或者查询与资源相关的选项和需求常见的请求报头User-Agent:包含发出请求的⽤户信息。

Accept:Accept请求报头域⽤于指定客户端接受哪些类型的信息。

eg:Accept:image/gif,表明客户端希望接受GIF图象格式的资源;Accept:text/html,表明客户端希望接受html⽂本。

Referer:告诉服务器我是从哪个页⾯链接过来的Cookie:⾝份凭证HTTP响应包HTTP响应也是由三个部分组成,分别是:状态⾏、消息报头、响应正⽂。

状态⾏格式:HTTP-Version Status-Code Reason-Phrase CRLFHTTP-Version表⽰服务器HTTP协议的版本Status-Code表⽰服务器发回的响应状态代码Reason-Phrase表⽰状态代码的⽂本描述。

常见的状态码200 OK 客户端请求成功400 Bad Request 客户端请求有语法错误,不能被服务器所理解403 Forbidden 服务器收到请求,但是拒绝提供服务404 Not Found 请求资源不存在500 Internal Server Error 服务器发⽣不可预期的错误503 Server Unavailable 服务器当前不能处理客户端的请求,⼀段时间后可能恢复正常常见的响应头Server Web服务器名称Set-cookie 服务器向客户端发送的信息Location 服务器通过这个头告诉浏览器去访问哪个页⾯,浏览器接收到这个请求后,通常会⽴刻访问Location头所指向的页⾯,通过配合302状态码Refresh 服务器通过这个告诉浏览器定时刷新浏览器。

HTTP报文(首部字段)

HTTP报文(首部字段)

HTTP报⽂(⾸部字段)HTTP报⽂请求报⽂/响应报⽂结构: 报⽂⾸部 + (可选)报⽂主体(两者通过空⾏CR + LF来划分)使⽤⾸部字段是为了给浏览器和服务器提供报⽂主体⼤⼩、所使⽤的语⾔、认证信息等内容HTTP⾸部字段重复,这种情况在规范内尚未明确,根据浏览器内部处理逻辑的⽽不同,结果可能并不⼀致。

报⽂⾸部请求⾏/状态⾏请求⾏: 请求⽅法 + 请求URI(资源/CGI通⽤⽹关接⼝) + HTTP版本状态⾏: HTTP版本 + 状态码 + 原因短语⾸部字段(请求/响应⾸部字段 + 通⽤⾸部字段 + 实体⾸部字段)其他(在HTTP协议通信交互中使⽤到的⾸部字段,不限于RFC2616中定义的47种⾸部字段。

包括Cookie、Set-Cookie和Content-Disposition等在其他RFC中定义的⾸部字段)报⽂主体HTTP传输数据可按照数据原貌直接传输,也可以在传输过程中通过编码提升传输速率。

通常,报⽂主体等于实体主体。

只有当传输中进⾏编码操作时,实体主体的内容发⽣变化,才导致它和报⽂主体产⽣差异。

报⽂主体和实体主体的差异报⽂(message)是HTTP通信中的基本单位,由8位组字节流组成,通过HTTP通信传输实体(entity)作为请求或响应的有效何在数据(补充项)被传输,其内容由实体⾸部和实体主体组成内容编码内容编码指明应⽤在实体内容上的编码格式,并保持实体信息原样压缩。

内容编码后的实体由客户端接收并负责解码内容编码的⽅式gzip(GNU zip)由⽂件压缩程序 gzip(GNU zip)⽣成的编码格式(RFC1952),采⽤ Lempel-Ziv 算法(LZ77)及 32 位循环冗余校验(CyclicRedundancy Check,通称 CRC)。

nodejs中var zlib = require('zlib')vra gunzip = zlib.createGunzip()compress(UNIX系统的标准压缩)由 UNIX ⽂件压缩程序 compress ⽣成的编码格式,采⽤ Lempel-Ziv-Welch 算法(LZW)。

HTTP中header头部信息详解

HTTP中header头部信息详解

HTTP中header头部信息详解HTTP Request的Header信息1、HTTP请求⽅式如下表:GET向Web服务器请求⼀个⽂件POST向Web服务器发送数据让Web服务器进⾏处理PUT向Web服务器发送数据并存储在Web服务器内部HEAD检查⼀个对象是否存在DELETE从Web服务器上删除⼀个⽂件CONNECT对通道提供⽀持TRACE跟踪到服务器的路径OPTIONS查询Web服务器的性能说明:主要使⽤到“GET”和“POST”。

实例:POST /test/tupian/cm HTTP/1.1分成三部分:1. POST:HTTP请求⽅式2. /test/tupian/cm:请求Web服务器的⽬录地址(或者指令)3. HTTP/1.1: URI(Uniform Resource Identifier,统⼀资源标识符)及其版本备注:在Ajax中,对应method属性设置。

2、Host说明:请求的web服务器域名地址3、User-Agent说明:HTTP客户端运⾏的浏览器类型的详细信息。

通过该头部信息,web服务器可以判断到当前HTTP请求的客户端浏览器类别。

实例:User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.114、Accept说明:指定客户端能够接收的内容类型,内容类型中的先后次序表⽰客户端接收的先后次序。

例如:Accept:text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5备注:在Prototyp(1.5)的Ajax代码封装中,将Accept默认设置为“text/javascript, text/html, application/xml, text/xml, */*”。

HTTP请求与响应

HTTP请求与响应

HTTP请求与响应http请求由三部分组成,分别是:请求行、消息报头、请求正文请求行以一个方法符号开头,以空格分开,后面跟着请求的URI和协议的版本,格式如下:Method Request-URI HTTP-Version CRLF其中Method表示请求方法;Request-URI是一个统一资源标识符;HTTP-Version表示请求的HTTP协议版本;CRLF表示回车和换行(除了作为结尾的CRLF外,不允许出现单独的CR或LF字符)。

请求方法(所有方法全为大写)有多种,各个方法的解释如下:GET 请求获取Request-URI所标识的资源POST 在Request-URI所标识的资源后附加新的数据HEAD 请求获取由Request-URI所标识的资源的响应消息报头PUT 请求服务器存储一个资源,并用Request-URI作为其标识DELETE 请求服务器删除Request-URI所标识的资源TRACE 请求服务器回送收到的请求信息,主要用于测试或诊断CONNECT 保留将来使用OPTIONS 请求查询服务器的性能,或者查询与资源相关的选项和需求一.HTTP请求1.HTTP请求格式:<request line><headers><blank line>[<request-body>]在HTTP请求中,第一行必须是一个请求行(request line),用来说明请求类型、要访问的资源以及使用的HTTP版本。

紧接着是一个首部(header)小节,用来说明服务器要使用的附加信息。

在首部之后是一个空行,再此之后可以添加任意的其他数据[称之为主体(body)]。

2.GET与POST区别HTTP 定义了与服务器交互的不同方法如上所示,最基本的方法是GET 和POST。

GET与POST方法有以下区别:(1)在客户端,Get方式在通过URL提交数据,数据在URL中可以看到;POST方式,数据放置在HTML HEADER内提交。

HTTP请求和MIME介绍

HTTP请求和MIME介绍

HTTP请求和MIME介绍HTTP请求和MIME介绍HTTP请求由三部分组成,分别是:请求行,消息报头,请求正文。

请求行(格式):Method Request-URI HTTP-Version CRLFMethod:方法。

GET 请求获取由Request-URI所标识的资源。

POST 在Request-URI所标识的资源后附加新的数据。

HEAD 请求获取由Request-URI所标识的资源的响应消息报头。

PUT 请求服务器存储一个资源,并用Request-URI作为其标识。

DELETE 请求服务器删除由Request-URI所标识的资源。

TRACE 请求服务器回送收到的请求信息,主要用语测试或诊断。

CONNECT 保留将来使用。

OPTIONS 请求查询服务器的性能,或查询与资源相关的选项和需求。

Request-URI:统一资源标识。

HTTP-Version:HTTP的版本。

CRLF:回车换行。

(\r\n)例:GET /form.html HTTP/1.1 \r\nHTTP响应在接收和解释请求消息后,服务器会返回一个HTTP响应消息。

与HTTP请求类似,HTTP响应也是三个部分组成,分别是:状态行、消息报头、响应正文。

状态行:状态行由协议版本、数字形式的状态代码、及相应的状态描述,各元素之间以空格分隔。

格式: HTTP-Version Status-Code Reason-Phrase CRLF例如: HTTP/1.1 200 OK \r\n状态代码:状态代码由3位数字组成,表示请求是否被理解或被满足。

状态描述:状态描述给出了关于状态代码的简短的文字描述。

状态代码的第一个数字定义了响应的类别,后面两位没有具体的分类。

第一个数字有五种可能的取值:- 1xx: 指示信息—表示请求已接收,继续处理。

- 2xx: 成功—表示请求已经被成功接收、理解、接受。

- 3xx: 重定向—要完成请求必须进行更进一步的操作。

HTTP请求方式中8种请求方法

HTTP请求方式中8种请求方法

HTTP请求⽅式中8种请求⽅法简单介绍HTTP请求的⽅法:HTTP/1.1协议中共定义了⼋种⽅法(有时也叫“动作”),来表明Request-URL指定的资源不同的操作⽅式HTTP1.0定义了三种请求⽅法: GET, POST 和 HEAD⽅法。

HTTP1.1新增了五种请求⽅法:OPTIONS, PUT, DELETE, TRACE 和 CONNECT ⽅法1、OPTIONS返回服务器针对特定资源所⽀持的HTTP请求⽅法,也可以利⽤向web服务器发送‘*’的请求来测试服务器的功能性2、HEAD向服务器索与GET请求相⼀致的响应,只不过响应体将不会被返回。

这⼀⽅法可以再不必传输整个响应内容的情况下,就可以获取包含在响应⼩消息头中的元信息。

3、GET向特定的资源发出请求。

注意:GET⽅法不应当被⽤于产⽣“副作⽤”的操作中,例如在Web Application中,其中⼀个原因是GET可能会被⽹络蜘蛛等随意访问。

Loadrunner中对应get请求函数:web_link和web_url4、POST向指定资源提交数据进⾏处理请求(例如提交表单或者上传⽂件)。

数据被包含在请求体中。

POST请求可能会导致新的资源的建⽴和/或已有资源的修改。

Loadrunner中对应POST请求函数:web_submit_data,web_submit_form5、PUT向指定资源位置上传其最新内容6、DELETE请求服务器删除Request-URL所标识的资源7、TRACE回显服务器收到的请求,主要⽤于测试或诊断8、CONNECTHTTP/1.1协议中预留给能够将连接改为管道⽅式的代理服务器。

注意:1)⽅法名称是区分⼤⼩写的,当某个请求所针对的资源不⽀持对应的请求⽅法的时候,服务器应当返回状态码405(Mothod Not Allowed);当服务器不认识或者不⽀持对应的请求⽅法时,应返回状态码501(Not Implemented)。

HTTP 报头,Content-disposition

HTTP 报头,Content-disposition

当然filename参数可以包含路径信息,但User-Agnet会忽略掉这些信息,只会把路径信息的最后一部分做为文件名。当你在响应类型为 application/octet- stream情况下使用了这个头信息的话,那就意味着你不想直接显示内容,而是弹出一个”文件下载”的对话框,接下来就是由你来决定“打开”还是“保存” 了。
////attachment --- 作为附件下载
////inline --- 在线打开
HttpContext.Current.Response.AddHeader("Content-Length", fileSize.ToString());
byte[] fileBuffer = new byte[fileSize];
将上述需求进行归我给出如下例子代码:
public static void ToDownload(string serverfilpath,string filename)
{
FileStream fileStream = new FileStream(serverfilpath, FileMode.Open);
w3c的说明:/Protocols/rfc2616/rfc2616-sec19.html
Content-Disposition的使用和注意事项
2008年08月27日 星期三 下午 07:21Content-Disposition的使用和注意事项
最近不少Web技术圈内的朋友在讨论协议方面的事情,有的说web开发者应该熟悉web相关的协议,有的则说不用很了解。个人认为这要分层次来看待这个问 题,对于一个新手或者刚入门的web开发人员而言,研究协议方面的东西可能会使得web开发失去趣味性、抹煞学习积极性,这类人应该更多的了解基本的 Web技术使用。而对于在该行业工作多年的老鸟来说,协议相关的内容、标准相关内容应该尽量多些的了解,因为只有这样才能使得经手的web系统更加优秀 (安全、漂亮、快速、兼容性好、体验好……)。本文我们来说一下MIME 协议的一个扩展Content-disposition。
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

HTTP头字段包括4类:general-header ;request-header ;response-header ;entity-header .********************************************************************* **********General Header Fields=============================general header是request、response都可用的, 但是不能用于entity.--Cache-Control--Connection--Date--Pragma--Trailer--Transfer-Encoding--Upgrade--Via--Warning********************************************************************* **********Request Header Fields======================request-header fields 允许客户端传递关于request和客户端的附加信息到服务端,--Accept--Accept-Charset--Accept-Encoding--Accept-Language--Authorization--Expect--From--Host--If-Match--If-Modified-Since--If-None-Match--If-Range--If-Unmodified-Since--Proxy-Authorization--Range--Referer--TE--User-Agent********************************************************************* **********Response Header Fields===============================response-header fields 允许服务端传递关于response的、不能放到Status-Line 的附加信息。

这些头给出关于服务端的信息。

--Accept-Ranges--Age--ETag--Location--Proxy-Authenticate--Retry-After--Server--Vary--WWW-Authenticate********************************************************************* **********Entity Header Fields========================Entity-header fields 定义关于entity-body的metainformation(标题字段数据), 如果当前没有body, 则定义被request确定的资源信息.一些metainformation是可选的; 一些是必须的。

--Allow--Content-Encoding--Content-Language--Content-Length--Content-Location--Content-MD5--Content-Range--Content-Type--Expires--extension-header一、基础篇HTTP(HyperTextTransferProtocol)是超文本传输协议的缩写,它用于传送WWW 方式的数据,关于HTTP协议的详细内容请参考RFC2616。

HTTP协议采用了请求/响应模型。

客户端向服务器发送一个请求,请求头包含请求的方法、URI、协议版本、以及包含请求修饰符、客户信息和内容的类似于MIME的消息结构。

服务器以一个状态行作为响应,相应的内容包括消息协议的版本,成功或者错误编码加上包含服务器信息、实体元信息以及可能的实体内容。

通常HTTP消息包括客户机向服务器的请求消息和服务器向客户机的响应消息。

这两种类型的消息由一个起始行,一个或者多个头域,一个只是头域结束的空行和可选的消息体组成。

HTTP的头域包括通用头,请求头,响应头和实体头四个部分。

每个头域由一个域名,冒号(:)和域值三部分组成。

域名是大小写无关的,域值前可以添加任何数量的空格符,头域可以被扩展为多行,在每行开始处,使用至少一个空格或制表符。

1、通用头域通用头域包含请求和响应消息都支持的头域,通用头域包含Cache-Control、Connection、Date、Pragma、Transfer-Encoding、Upgrade、Via。

对通用头域的扩展要求通讯双方都支持此扩展,如果存在不支持的通用头域,一般将会作为实体头域处理。

下面简单介绍几个在UPnP 消息中使用的通用头域。

Cache-Control头域Cache-Control指定请求和响应遵循的缓存机制。

在请求消息或响应消息中设置Cache-Control并不会修改另一个消息处理过程中的缓存处理过程。

请求时的缓存指令包括no-cache、no- store、max-age、max-stale、min-fresh、only-if-cached,响应消息中的指令包括public、private、no-cache、no-store、no-transform、must-revalidate、proxy-revalidate、max-age。

各个消息中的指令含义如下:Public指示响应可被任何缓存区缓存。

Private指示对于单个用户的整个或部分响应消息,不能被共享缓存处理。

这允许服务器仅仅描述当用户的部分响应消息,此响应消息对于其他用户的请求无效。

no-cache指示请求或响应消息不能缓存no-store用于防止重要的信息被无意的发布。

在请求消息中发送将使得请求和响应消息都不使用缓存。

max-age指示客户机可以接收生存期不大于指定时间(以秒为单位)的响应。

min-fresh指示客户机可以接收响应时间小于当前时间加上指定时间的响应。

max-stale指示客户机可以接收超出超时期间的响应消息。

如果指定max-stale消息的值,那么客户机可以接收超出超时期指定值之内的响应消息。

Date头域Date头域表示消息发送的时间,时间的描述格式由rfc822定义。

例如,Date:Mon,31Dec200104:25:57GMT。

Date描述的时间表示世界标准时,换算成本地时间,需要知道用户所在的时区。

Pragma头域Pragma头域用来包含实现特定的指令,最常用的是Pragma:no-cache。

在HTTP/1.1协议中,它的含义和Cache-Control:no-cache相同。

2、请求消息请求消息的第一行为下面的格式:Method SP Request-URI SP HTTP-Version CRLFMethod表示对于Request-URI完成的方法,这个字段是大小写敏感的,包括OPTIONS、GET、HEAD、POST、PUT、DELETE、TRACE。

方法GET和HEAD 应该被所有的通用WEB服务器支持,其他所有方法的实现是可选的。

GET方法取回由Request-URI标识的信息。

HEAD方法也是取回由Request-URI标识的信息,只是可以在响应时,不返回消息体。

POST方法可以请求服务器接收包含在请求中的实体信息,可以用于提交表单,向新闻组、BBS、邮件群组和数据库发送消息。

SP表示空格。

Request-URI遵循URI格式,在此字段为星号(*)时,说明请求并不用于某个特定的资源地址,而是用于服务器本身。

HTTP-Version表示支持的HTTP版本,例如为HTTP/1.1。

CRLF表示换行回车符。

请求头域允许客户端向服务器传递关于请求或者关于客户机的附加信息。

请求头域可能包含下列字段Accept、Accept-Charset、Accept- Encoding、Accept-Language、Authorization、From、Host、If-Modified-Since、If- Match、If-None-Match、If-Range、If-Range、If-Unmodified-Since、Max-Forwards、Proxy-Authorization、Range、Referer、User-Agent。

对请求头域的扩展要求通讯双方都支持,如果存在不支持的请求头域,一般将会作为实体头域处理。

典型的请求消息:GEThttp://class/download.microtool.de:80/somedata.exeHost:download.microtool.deAccept:*/*Pragma:no-cacheCache-Control:no-cacheReferer:http://class/download.microtool.de/User-Agent:Mozilla/4.04[en](Win95;I;Nav)Range:bytes=554554-上例第一行表示HTTP客户端(可能是浏览器、下载程序)通过GET方法获得指定URL下的文件。

棕色的部分表示请求头域的信息,绿色的部分表示通用头部分。

Host头域Host头域指定请求资源的Intenet主机和端口号,必须表示请求url的原始服务器或网关的位置。

HTTP/1.1请求必须包含主机头域,否则系统会以400状态码返回。

Referer头域Referer头域允许客户端指定请求uri的源资源地址,这可以允许服务器生成回退链表,可用来登陆、优化cache等。

他也允许废除的或错误的连接由于维护的目的被追踪。

如果请求的uri没有自己的uri地址,Referer不能被发送。

如果指定的是部分uri地址,则此地址应该是一个相对地址。

Range头域Range头域可以请求实体的一个或者多个子范围。

例如,表示头500个字节:bytes=0-499表示第二个500字节:bytes=500-999表示最后500个字节:bytes=-500表示500字节以后的范围:bytes=500-第一个和最后一个字节:bytes=0-0,-1同时指定几个范围:bytes=500-600,601-999但是服务器可以忽略此请求头,如果无条件GET包含Range请求头,响应会以状态码206(PartialContent)返回而不是以200(OK)。

User-Agent头域User-Agent头域的内容包含发出请求的用户信息。

3、响应消息响应消息的第一行为下面的格式:HTTP-Version SP Status-Code SP Reason-Phrase CRLFHTTP-Version表示支持的HTTP版本,例如为HTTP/1.1。

相关文档
最新文档