HTTP协议 1-3 章 主要内容的一句话介绍

27 views
Skip to first unread message

靳雄飞

unread,
Nov 9, 2009, 8:25:32 AM11/9/09
to dus...@googlegroups.com
  • HTTP基于 request/response 模型。
  • 从版本1.1开始，支持在一次connection上完成多次交互。
  • HTTP通常基于TCP/IP，但不是必须的。
  • 从客户端发到服务端的request，第一行包括 请求方法、URL、协议版本，后续行是协议参数，格式类似于MIME
  • 从服务器返回的response，第一行是状态，包括协议版本和状态码，后续行是返回的实际内容
  • 从客户端到你请求的服务器中间，有可能存在三种常见的 intermediary: proxy, gateway, and tunnel
  • proxy 是负责消息转发的机构，可能会根据情况重写请求的URI，以保证请求能够到达正确的目的地
  • gateway 是负责代收消息的机构，经常放置在真正的Server之前，完成必要的协议翻译。
  • tunnel 负责消息中继，让消息在不同的网段间顺利传递，不对消息做任何修改。
  • HTTP协议的各种语法用BNF描述。BNF在计算机文献中使用广泛，尤其在各种RFC和编程语言规范中，我翻译了一下，可以看看这里：http://groups.google.com/group/dusplan/t/f6ad664c55598028
  • URL是格式化的字符串，用于表示一个被请求的资源（但并不限于HTTP协议）。URL有绝对和相对两种形式。
  • HTTP协议本身并未限制URL的长度，但Server可以根据自己的处理能力，对于超过长度限制的URL返回状态码：414
  • 因为某种历史原因，HTTP协议支持三种日期/时间格式，而且实现者必须保证全都支持。
  • 日期/时间 必须用格林尼治时间。
  • 以上关于日期的约束，仅限于HTTP协议自身，与基于HTTP协议传输的内容中的日期格式无关。
  • HTTP协议的参数中，有一个很重要的参数是charset，也就是字符集，经常碰到的乱码问题与此有一定的关系。java程序中常见的 response.setContentType ("text/html;charset=utf-8"); 的作用就是设置字符集。HTTP协议的默认字符集是ISO-8859-1，为了保险起见，建议总是显式的设置字符集。参考资料：http://www.w3.org/International/O-HTTP-charset
  • HTTP协议头的实例可以参见：http://www.joinphp.cn/blog/?p=29。还有其它几个重要的协议参数，包括：content-encoding, transfer-encoding, media-type,multi-part等，很难用一句话总结，请大家去看协议第三章。

一名

unread,
Nov 10, 2009, 1:15:09 AM11/10/09
to 读S计划 - Java Web 方向

On 11月9日, 下午9时25分, 靳雄飞 <jinx...@gmail.com> wrote:
> - HTTP基于 request/response 模型。
> - 从版本1.1开始，支持在一次connection上完成多次交互。
> - HTTP通常基于TCP/IP，但不是必须的。
> -
> - 从客户端发到服务端的request，第一行包括 请求方法、URL、协议版本，后续行是协议参数，格式类似于MIME
> - 从服务器返回的response，第一行是状态，包括协议版本和状态码，后续行是返回的实际内容
> -
> - 从客户端到你请求的服务器中间，有可能存在三种常见的 intermediary: proxy, gateway, and tunnel
> - proxy 是负责消息转发的机构，可能会根据情况重写请求的URI，以保证请求能够到达正确的目的地
> - gateway 是负责代收消息的机构，经常放置在真正的Server之前，完成必要的协议翻译。
> - tunnel 负责消息中继，让消息在不同的网段间顺利传递，不对消息做任何修改。
> -
> - HTTP协议的各种语法用BNF描述。BNF在计算机文献中使用广泛，尤其在各种RFC和编程语言规范中，我翻译了一下，可以看看这里：
> http://groups.google.com/group/dusplan/t/f6ad664c55598028
> - URL是格式化的字符串，用于表示一个被请求的资源（但并不限于HTTP协议）。URL有绝对和相对两种形式。
> - HTTP协议本身并未限制URL的长度，但Server可以根据自己的处理能力，对于超过长度限制的URL返回状态码：414
> -
> - 因为某种历史原因，HTTP协议支持三种日期/时间格式，而且实现者必须保证全都支持。
> - 日期/时间 必须用格林尼治时间。
> - 以上关于日期的约束，仅限于HTTP协议自身，与基于HTTP协议传输的内容中的日期格式无关。
> -
> - HTTP协议的参数中，有一个很重要的参数是charset，也就是字符集，经常碰到的乱码问题与此有一定的关系。java程序中常见的


> response.setContentType ("text/html;charset=utf-8");
> 的作用就是设置字符集。HTTP协议的默认字符集是ISO-8859-1，为了保险起见，建议总是显式的设置字符集。参考资料：
> http://www.w3.org/International/O-HTTP-charset

> -
> - HTTP协议头的实例可以参见：http://www.joinphp.cn/blog/?p=29。还有其它几个重要的协议参数，包括：content-encoding,
> transfer-encoding, media-type,multi-part等，很难用一句话总结，请大家去看协议第三章。

任水

unread,
Nov 10, 2009, 8:37:23 PM11/10/09
to dus...@googlegroups.com

下面是协议中对tunnel的定义，能大概理解其意思，但不知tunnel一般用于哪种具体场景？

 

tunnel

An intermediary program which is acting as a blind relay between two connections. Once active, a tunnel is not

considered a party to the HTTP communication, though the tunnel may have been initiated by an HTTP request.

The tunnel ceases to exist when both ends of the relayed connections are closed.

 

发件人: dus...@googlegroups.com [mailto:dus...@googlegroups.com] 代表 靳雄飞
发送时间: 2009年11月9日星期一 21:26
收件人: dus...@googlegroups.com
主题: [dusplan] HTTP协议 1-3 章 主要内容的一句话介绍

任水

unread,
Nov 11, 2009, 6:26:23 AM11/11/09
to dus...@googlegroups.com

感觉Proxy跟gateway的差别还是挺细微的。

 

虽然文档中将proxy定位为forward，gateway定位为receive；但proxy不也是需要先receive再forward吗，gateway receive之后不也是要forward给其它server吗？

 

 也就是说两者都要充当forward和receive的角色

 

起码从概念上区分不开两者， 迷惑啊

 

发件人: 任水 [mailto:ren...@gmail.com]
发送时间: 2009年11月11日星期三 9:37
收件人: 'dus...@googlegroups.com'
主题: 答复: [dusplan] HTTP协议 1-3 章 主要内容的一句话介绍

 

下面是协议中对tunnel的定义，能大概理解其意思，但不知tunnel一般用于哪种具体场景？

 

tunnel

An intermediary program which is acting as a blind relay between two connections. Once active, a tunnel is not

considered a party to the HTTP communication, though the tunnel may have been initiated by an HTTP request.

The tunnel ceases to exist when both ends of the relayed connections are closed.

 

发件人: dus...@googlegroups.com [mailto:dus...@googlegroups.com] 代表 靳雄飞
发送时间: 2009年11月9日星期一 21:26
收件人: dus...@googlegroups.com
主题: [dusplan] HTTP协议 1-3 章 主要内容的一句话介绍

 

  • HTTP基于 request/response 模型。

靳雄飞

unread,
Nov 11, 2009, 10:21:43 AM11/11/09
to dus...@googlegroups.com
因为我们都不是proxy或者gateway的实现者，所以只能从规范原文中去分析两者的差异。
从下面的原文中，可以看出来，gateway和proxy的工作原理应该是类似的，
 
但proxy必须实现本规范所规定的client和server两种特性，
对于经过此proxy的客户端，它表现为server，而它自身又作为客户端向真正的目标server发起请求。
proxy可以对客户端是透明的，也可以不透明。
 
gateway则通常是对客户端透明的，gateway本身就可以代表被请求的最终server。
 
 
 
这是我的理解，欢迎更多人参与讨论。
 
 
 
proxy
      An intermediary program which acts as both a server and a client
      for the purpose of making requests on behalf of other clients.
      Requests are serviced internally or by passing them on, with
      possible translation, to other servers. A proxy MUST implement
      both the client and server requirements of this specification. A
      "transparent proxy" is a proxy that does not modify the request or
      response beyond what is required for proxy authentication and
      identification. A "non-transparent proxy" is a proxy that modifies
      the request or response in order to provide some added service to
      the user agent, such as group annotation services, media type
      transformation, protocol reduction, or anonymity filtering. Except
      where either transparent or non-transparent behavior is explicitly
      stated, the HTTP proxy requirements apply to both types of
      proxies.

   gateway
      A server which acts as an intermediary for some other server.
      Unlike a proxy, a gateway receives requests as if it were the
      origin server for the requested resource; the requesting client
      may not be aware that it is communicating with a gateway.
2009/11/11 任水 <ren...@gmail.com>

任水

unread,
Nov 11, 2009, 7:41:57 PM11/11/09
to dus...@googlegroups.com

有道理

 

靳雄飞
发送时间: 2009年11月11日星期三 23:22
收件人: dus...@googlegroups.com
主题: Re: 答复: [dusplan] HTTP协议 1-3 章 主要内容的一句话介绍

2009/11/11 任水 <ren...@gmail.com>

<br

徐培华

unread,
Nov 11, 2009, 7:51:51 PM11/11/09
to dus...@googlegroups.com
多谢老大的总结。

2009/11/12 任水 <ren...@gmail.com>

任水

unread,
Nov 15, 2009, 9:10:11 AM11/15/09
to dus...@googlegroups.com

各位好，

 

我试着以协议栈的方式理解一下charset，content-encoding，transfer-encoding，有不对的地方恳请指正。

 

 

                          Sender                                                                                                                                                                 Recipient

 

                我要发送“中国”                                                                                                                                  奥，它给我发的是“中国”啊

                             

 

“中国”在gbk编码(CHARSET)的                                                                                                         http头部charset指定的是gbk，用gbk对0111111解码得到

八进制值为“0111111”(这个值是捏造的)                                                                                                         “中国”

                       

 

经Gzip（content-encoding）压缩后，只需发送“0222”                                                                       对“0222”解压缩得到0111111

 


由于底层传输设备的限制，内容必须是

成块（transfer-encoding）发送，这样发送的内容就变成了

         “0333

0444”                                                                                                                                                                 将块中的有用数据提取出来，得到“0222”

 

 

 

 

 

 

 

 

 

 

 

 

                        

发件人: dus...@googlegroups.com [mailto:dus...@googlegroups.com] 代表 靳雄飞
发送时间: 2009年11月9日星期一 21:26
收件人: dus...@googlegroups.com
主题: [dusplan] HTTP协议 1-3 章 主要内容的一句话介绍

 

  • HTTP基于 request/response 模型。

靳雄飞

unread,
Nov 15, 2009, 9:48:55 AM11/15/09
to dus...@googlegroups.com
感谢你的辛苦付出！！
 
不过，从我这里看到的格式都是乱的。
建议你发一张图片，或者做一个页面（看看Google Group右边的菜单），Google Group的贴子对格式的支持比较弱。。
 
不知道别人能不能看到正确的格式。

2009/11/15 任水 <ren...@gmail.com>

任水

unread,
Nov 15, 2009, 7:54:53 PM11/15/09
to dus...@googlegroups.com

呵呵，重发一下

 

 

发件人: 任水 [mailto:ren...@gmail.com]
发送时间: 2009年11月15日星期日 22:10
收件人: 'dus...@googlegroups.com'
主题: 理解charset，content-encoding，transfer-encoding

 

各位好，

 

我试着以协议栈的方式理解一下charset，content-encoding，transfer-encoding，有不对的地方恳请指正。

 

 

                          Sender                                                                                                                                                                 Recipient

 

                我要发送“中国”                                                                                                                                  奥，它给我发的是“中国”啊

                             

 

“中国”在gbk编码(CHARSET)的                                                                                                         http头部charset指定的是gbk，用gbk对0111111解码得到

八进制值为“0111111”(这个值是捏造的)                                                                                                         “中国”

                       

 

经Gzip（content-encoding）压缩后，只需发送“0222”                                                                       对“0222”解压缩得到0111111

 


由于底层传输设备的限制，内容必须是

成块（transfer-encoding）发送，这样发送的内容就变成了

         “0333

0444”                                                                                                                                                                 将块中的有用数据提取出来，得到“0222”

 

 

 

 

 

 

 

 

 

 

 

 

                        

发件人: dus...@googlegroups.com [mailto:dus...@googlegroups.com] 代表 靳雄飞
发送时间: 2009年11月9日星期一 21:26
收件人: dus...@googlegroups.com
主题: [dusplan] HTTP协议 1-3 章 主要内容的一句话介绍

 

  • HTTP基于 request/response 模型。

靳雄飞

unread,
Nov 16, 2009, 9:05:25 AM11/16/09
to dus...@googlegroups.com
我觉得挺准确，挺直观的。
 
谢谢你的贡献。
 
 
transfer-coding和content-coding的差异就一句话：
This differs from a content coding in that the transfer-coding is a property of the message, not of the original entity.
也就是说，content-coding表明一个entity的编码方式，而transfer-coding表明整个消息体的编码格式。
 
 
今天发现协议里似乎有一处引用错误：
The Internet Assigned Numbers Authority (IANA) acts as a registry for
   transfer-coding value tokens. Initially, the registry contains the
   following tokens: "chunked" (section 3.6.1), "identity" (section
   3.6.2), "gzip" (section 3.5), "compress" (section 3.5), and "deflate"
   (section 3.5).
identiy指向section 3.6.2，但似乎并没有这一节。
 


 
2009/11/16 任水 <ren...@gmail.com>

Xin Li

unread,
Nov 16, 2009, 9:28:01 AM11/16/09
to dus...@googlegroups.com

看起来果然更容易理解，做过相关内容的一看明白，没做过的想要了解更多相关约定也可以自己去查了~

congcong

unread,
Nov 16, 2009, 9:30:59 AM11/16/09
to 读S计划 - Java Web 方向
还是老大仔细！RFC竟然也能出现引用错误啊，"identity" (section 3.6.2)应该是(section 3.5)才对。

On Nov 16, 10:05 pm, 靳雄飞 <jinx...@gmail.com> wrote:
> 我觉得挺准确，挺直观的。
>
> 谢谢你的贡献。
>
> transfer-coding和content-coding的差异就一句话：
> This differs from a content coding in that the transfer-coding is a property
> of the message, not of the original entity.
> 也就是说，content-coding表明一个entity的编码方式，而transfer-coding表明整个消息体的编码格式。
>
> 今天发现协议里似乎有一处引用错误：
> The Internet Assigned Numbers Authority (IANA) acts as a registry for
> transfer-coding value tokens. Initially, the registry contains the

> following tokens: "chunked" (section 3.6.1), *"identity" (section
> 3.6.2)*, "gzip" (section 3.5), "compress" (section 3.5), and "deflate"


> (section 3.5).
> identiy指向section 3.6.2，但似乎并没有这一节。
>

> 2009/11/16 任水 <rens...@gmail.com>
>
>
>
> > 呵呵，重发一下
>
> > *发件人:* 任水 [mailto:rens...@gmail.com]
> > *发送时间:* 2009年11月15日星期日 22:10
> > *收件人:* 'dus...@googlegroups.com'
> > *主题:* 理解charset，content-encoding，transfer-encoding


>
> > 各位好，
>
> > 我试着以协议栈的方式理解一下charset，content-encoding，transfer-encoding，有不对的地方恳请指正。
>
> > Sender
> > Recipient
>
> > 我要发送"中国"
> > 奥，它给我发的是"中国"啊
>

> > "中国"在gbk编码(CHARSET)的
> > http头部charset指定的是gbk，用gbk对0111111解码得到
>
> > 八进制值为"0111111"(这个值是捏造的)
> > "中国"
>

> > 经Gzip（content-encoding）压缩后，只需发送"0222"
> > 对"0222"解压缩得到0111111
>

> > 由于底层传输设备的限制，内容必须是
>
> > 成块（transfer-encoding）发送，这样发送的内容就变成了
>
> > "0333
>

> > 0444"
> > 将块中的有用数据提取出来，得到"0222"
>
> > *发件人:* dus...@googlegroups.com [mailto:dus...@googlegroups.com] *代表 *靳雄飞
> > *发送时间:* 2009年11月9日星期一 21:26
> > *收件人:* dus...@googlegroups.com
> > *主题:* [dusplan] HTTP协议 1-3 章 主要内容的一句话介绍


>
> > - HTTP基于 request/response 模型。
> > - 从版本1.1开始，支持在一次connection上完成多次交互。
> > - HTTP通常基于TCP/IP，但不是必须的。
> > -
> > - 从客户端发到服务端的request，第一行包括 请求方法、URL、协议版本，后续行是协议参数，格式类似于MIME
> > - 从服务器返回的response，第一行是状态，包括协议版本和状态码，后续行是返回的实际内容
> > -
> > - 从客户端到你请求的服务器中间，有可能存在三种常见的 intermediary: proxy, gateway, and tunnel
> > - proxy 是负责消息转发的机构，可能会根据情况重写请求的URI，以保证请求能够到达正确的目的地
> > - gateway 是负责代收消息的机构，经常放置在真正的Server之前，完成必要的协议翻译。
> > - tunnel 负责消息中继，让消息在不同的网段间顺利传递，不对消息做任何修改。
> > -

> > - HTTP协议的各种语法用BNF描述。BNF在计算机文献中使用广泛，尤其在各种RFC和编程语言规范中，我翻译了一下，可以看看这里：
> > http://groups.google.com/group/dusplan/t/f6ad664c55598028


> > - URL是格式化的字符串，用于表示一个被请求的资源（但并不限于HTTP协议）。URL有绝对和相对两种形式。
> > - HTTP协议本身并未限制URL的长度，但Server可以根据自己的处理能力，对于超过长度限制的URL返回状态码：414
> > -
> > - 因为某种历史原因，HTTP协议支持三种日期/时间格式，而且实现者必须保证全都支持。
> > - 日期/时间 必须用格林尼治时间。
> > - 以上关于日期的约束，仅限于HTTP协议自身，与基于HTTP协议传输的内容中的日期格式无关。
> > -

> > - HTTP协议的参数中，有一个很重要的参数是charset，也就是字符集，经常碰到的乱码问题与此有一定的关系。java程序中常见的 response.setContentType


> > ("text/html;charset=utf-8"); 的作用就是设置字符集。HTTP协议的默认字符集是ISO-8859-1
> > ，为了保险起见，建议总是显式的设置字符集。参考资料：
> > http://www.w3.org/International/O-HTTP-charset

> > -
> > - HTTP协议头的实例可以参见：http://www.joinphp.cn/blog/?p=29。还有其它几个重要的协议参数，包括：content-encoding,
> > transfer-encoding, media-type,multi-part等，很难用一句话总结，请大家去看协议第三章。
>
> image009.png
> < 1KViewDownload
>
> image014.png
> < 1KViewDownload
>
> image012.png
> < 1KViewDownload
>
> image008.png
> 30KViewDownload
>
> image010.png
> < 1KViewDownload
>
> image011.png
> < 1KViewDownload
>
> image015.png
> < 1KViewDownload
>
> image013.png
> < 1KViewDownload

cloudxpc

unread,
Nov 19, 2009, 8:41:21 PM11/19/09
to 读S计划 - Java Web 方向
提个小问题：

- 从客户端发到服务端的request，第一行包括 请求方法、URL、协议版本，后续行是协议参数，格式类似于MIME

请求第一行包括的应该是URI而不是URL吧？


- URL是格式化的字符串，用于表示一个被请求的资源（但并不限于HTTP协议）。URL有绝对和相对两种形式。

这句话，也应该是URI有两种形式而不是URL吧？


顺便请教一下，URI是指一个资源路径，URL就是类似http这样的scheme加上域名和端口，后面再跟URI，这就构成了URL。这样理解不知有
误么？


On Nov 9, 9:25 pm, 靳雄飞 <jinx...@gmail.com> wrote:
> - HTTP基于 request/response 模型。
> - 从版本1.1开始，支持在一次connection上完成多次交互。
> - HTTP通常基于TCP/IP，但不是必须的。
> -
> - 从客户端发到服务端的request，第一行包括 请求方法、URL、协议版本，后续行是协议参数，格式类似于MIME
> - 从服务器返回的response，第一行是状态，包括协议版本和状态码，后续行是返回的实际内容
> -
> - 从客户端到你请求的服务器中间，有可能存在三种常见的 intermediary: proxy, gateway, and tunnel
> - proxy 是负责消息转发的机构，可能会根据情况重写请求的URI，以保证请求能够到达正确的目的地
> - gateway 是负责代收消息的机构，经常放置在真正的Server之前，完成必要的协议翻译。
> - tunnel 负责消息中继，让消息在不同的网段间顺利传递，不对消息做任何修改。
> -

> - HTTP协议的各种语法用BNF描述。BNF在计算机文献中使用广泛，尤其在各种RFC和编程语言规范中，我翻译了一下，可以看看这里：
> http://groups.google.com/group/dusplan/t/f6ad664c55598028


> - URL是格式化的字符串，用于表示一个被请求的资源（但并不限于HTTP协议）。URL有绝对和相对两种形式。
> - HTTP协议本身并未限制URL的长度，但Server可以根据自己的处理能力，对于超过长度限制的URL返回状态码：414
> -
> - 因为某种历史原因，HTTP协议支持三种日期/时间格式，而且实现者必须保证全都支持。
> - 日期/时间 必须用格林尼治时间。
> - 以上关于日期的约束，仅限于HTTP协议自身，与基于HTTP协议传输的内容中的日期格式无关。
> -

> - HTTP协议的参数中，有一个很重要的参数是charset，也就是字符集，经常碰到的乱码问题与此有一定的关系。java程序中常见的


> response.setContentType ("text/html;charset=utf-8");
> 的作用就是设置字符集。HTTP协议的默认字符集是ISO-8859-1，为了保险起见，建议总是显式的设置字符集。参考资料：
> http://www.w3.org/International/O-HTTP-charset

> -
> - HTTP协议头的实例可以参见：http://www.joinphp.cn/blog/?p=29。还有其它几个重要的协议参数，包括：content-encoding,
> transfer-encoding, media-type,multi-part等，很难用一句话总结，请大家去看协议第三章。

靳雄飞

unread,
Nov 19, 2009, 10:57:40 PM11/19/09
to dus...@googlegroups.com
URI和URL两个名词比较混淆，这是公认的，其实它们没有本质的差异，
或者在HTTP的范畴内，可以认为 URL 是 URI 的特例。
 
URI 泛泛的为资源设定一个唯一的定位符（Identifier），而URL 包含了如何获取资源的信息（Locator）。
 
可以参考这篇文章：
2009/11/20 cloudxpc <clou...@gmail.com>

cloudxpc

unread,
Nov 20, 2009, 12:28:06 AM11/20/09
to 读S计划 - Java Web 方向
上网查了一下，大多数人是这么理解的：URI是从某个根目录开始的包括文件夹名和资源名的一个路径地址。URL是带协议标准以及端口号等的以特定形式指
向一个资源的地址。在HTTP中的确差不多，有人说可以理解为URL是URI的子集，也就是说是URI的一种特殊表示。
另外，JAVA中相关的某些方法，具体我忘了，我记得有类似于getURI()和getURL()之类的两个方法，前者得到的好像是个目录路径，后者得
到的是http的全路径。


On Nov 20, 11:57 am, 靳雄飞 <jinx...@gmail.com> wrote:
> URI和URL两个名词比较混淆，这是公认的，其实它们没有本质的差异，
> 或者在HTTP的范畴内，可以认为 URL 是 URI 的特例。
>
> URI 泛泛的为资源设定一个唯一的定位符（Identifier），而URL 包含了如何获取资源的信息（Locator）。
>
> 可以参考这篇文章：http://www.damnhandy.com/2007/11/19/uri-vs-url-whats-the-difference/

> 2009/11/20 cloudxpc <cloud...@gmail.com>

> > > - HTTP协议头的实例可以参见：http://www.joinphp.cn/blog/?p=29。<http://www.joinphp.cn/blog/?p=29%E3%80%82>
> > 还有其它几个重要的协议参数，包括：content-encoding,
> > > transfer-encoding, media-type,multi-part等，很难用一句话总结，请大家去看协议第三章。- Hide quoted text -
>
> - Show quoted text -

Reply all
Reply to author
Forward
0 new messages