<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>梁剑的Blog &#187; Protocol</title>
	<atom:link href="http://icomes.net/category/%e6%8a%80%e6%9c%af%e7%ac%94%e8%ae%b0/protocol/feed/" rel="self" type="application/rss+xml" />
	<link>http://icomes.net</link>
	<description>做有趣的事，做有用的人</description>
	<lastBuildDate>Wed, 23 Jun 2010 16:04:55 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>RFC2616中关于HTTP Status Code的定义</title>
		<link>http://icomes.net/2009/10/12/rfc2616%e4%b8%ad%e5%85%b3%e4%ba%8ehttp-status-code%e7%9a%84%e5%ae%9a%e4%b9%89/</link>
		<comments>http://icomes.net/2009/10/12/rfc2616%e4%b8%ad%e5%85%b3%e4%ba%8ehttp-status-code%e7%9a%84%e5%ae%9a%e4%b9%89/#comments</comments>
		<pubDate>Mon, 12 Oct 2009 14:09:02 +0000</pubDate>
		<dc:creator>梁剑</dc:creator>
				<category><![CDATA[Protocol]]></category>
		<category><![CDATA[Web]]></category>
		<category><![CDATA[技术笔记]]></category>
		<category><![CDATA[读书笔记]]></category>
		<category><![CDATA[http]]></category>
		<category><![CDATA[rfc]]></category>

		<guid isPermaLink="false">http://icomes.net/?p=450</guid>
		<description><![CDATA[花了半天时间，看了一次http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
下面是相关的笔记和理解，
感觉很多Status Code在实际的BS通信中都不常见，
更多像是为了定义完备的协议语义，
而这些语义现在已经部分由更上层的协议或者应用实现。
1xx     Informational
100     Continue
&#160;&#160;&#160;&#160;如果server可能拒绝request，则client只发送header部分，试探server的反应
&#160;&#160;&#160;&#160;如果server接受，则返回100，于是client再发送剩余的body部分
101     Switch Protocol
2xx     Successful
200     OK
201     Created
&#160;&#160;&#160;&#160;有资源因Request而产生
202     Accepted
&#160;&#160;&#160;&#160;Request要求的动作已经被记录，但真正的动作要等待若干时间才执行，而且不保证一定执行
203     Non-Authoritative Information
204     No Content
&#160;&#160;&#160;&#160;google.cn的web server会返回
205     [...]]]></description>
			<content:encoded><![CDATA[<p>花了半天时间，看了一次<a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html" target="_blank">http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html</a></p>
<p>下面是相关的笔记和理解，<br />
感觉很多Status Code在实际的BS通信中都不常见，<br />
更多像是为了定义完备的协议语义，<br />
而这些语义现在已经部分由更上层的协议或者应用实现。</p>
<h3>1xx     Informational</h3>
<p><strong>100     Continue</strong><br />
&nbsp;&nbsp;&nbsp;&nbsp;如果server可能拒绝request，则client只发送header部分，试探server的反应<br />
&nbsp;&nbsp;&nbsp;&nbsp;如果server接受，则返回100，于是client再发送剩余的body部分<br />
<strong>101     Switch Protocol</strong></p>
<h3>2xx     Successful</h3>
<p><strong>200     OK<br />
201     Created</strong><br />
&nbsp;&nbsp;&nbsp;&nbsp;有资源因Request而产生<br />
<strong>202     Accepted</strong><br />
&nbsp;&nbsp;&nbsp;&nbsp;Request要求的动作已经被记录，但真正的动作要等待若干时间才执行，而且不保证一定执行<br />
<strong>203     Non-Authoritative Information<br />
204     No Content</strong><br />
&nbsp;&nbsp;&nbsp;&nbsp;google.cn的web server会返回<br />
<strong>205     Reset Content<br />
206     Partial Content</strong><br />
&nbsp;&nbsp;&nbsp;&nbsp;用于断点续传，起始位置由Range指定。（可以参考迅雷的输出）</p>
<h3>3xx     Redirection</h3>
<p>&nbsp;&nbsp;&nbsp;&nbsp;User Agent需要处理循环的问题<br />
<strong>300     Multiple Choices</strong><br />
&nbsp;&nbsp;&nbsp;&nbsp;目标已变，有若干个替代品可供选择<br />
<strong>301     Moved Permanently</strong><br />
&nbsp;&nbsp;&nbsp;&nbsp;目标URI在Location里定义，除了HEAD和GET请求外，不能自动重定向<br />
&nbsp;&nbsp;&nbsp;&nbsp;对SEO不会有负面作用<br />
<strong>302     Found</strong><br />
&nbsp;&nbsp;&nbsp;&nbsp;临时重定向，是否用Moved Temporarily这个名字比较合适？<br />
&nbsp;&nbsp;&nbsp;&nbsp;目标URI在Location里定义，除了HEAD和GET请求外，不能自动重定向<br />
&nbsp;&nbsp;&nbsp;&nbsp;对SEO有负面作用<br />
<strong>303     See Other</strong><br />
&nbsp;&nbsp;&nbsp;&nbsp;和302类似，但期待User Agent用GET来请求Location里指定的URI<br />
<strong>304     Not Modified</strong><br />
&nbsp;&nbsp;&nbsp;&nbsp;通常Request会带If-Modified-Since<br />
&nbsp;&nbsp;&nbsp;&nbsp;不能带message-body<br />
<strong>305     Use Proxy</strong><br />
&nbsp;&nbsp;&nbsp;&nbsp;期待User Agent会使用Location中指定的Proxy地址，来访问数据<br />
&nbsp;&nbsp;&nbsp;&nbsp;只能由origin server产生<br />
<strong>306     (not used)</strong><br />
&nbsp;&nbsp;&nbsp;&nbsp;之前的版本用过，已经废弃，作为保留字<br />
<strong>307     Temporary Redirect</strong><br />
&nbsp;&nbsp;&nbsp;&nbsp;没看出和302有什么不同<br />
&nbsp;&nbsp;&nbsp;&nbsp;只有HTTP/1.1支持</p>
<h3>4xx     Client Error</h3>
<p>&nbsp;&nbsp;&nbsp;&nbsp;在message-body中，可以自定义给User的提示<br />
<strong>400     Bad Request</strong><br />
&nbsp;&nbsp;&nbsp;&nbsp;server不能理解Request的格式<br />
&nbsp;&nbsp;&nbsp;&nbsp;用telnet可以很容易模拟<br />
<strong>401     Unauthorized</strong><br />
&nbsp;&nbsp;&nbsp;&nbsp;不能通过HTTP Authentication<br />
&nbsp;&nbsp;&nbsp;&nbsp;response header必须包含WWW-Authoricate，request header可能包含Authorization<br />
<strong>402     Payment Required</strong><br />
&nbsp;&nbsp;&nbsp;&nbsp;保留字<br />
<strong>403     Forbidden</strong><br />
&nbsp;&nbsp;&nbsp;&nbsp;如果不希望暴露过多的信息，可以用404代替<br />
<strong>404     Not Found</strong><br />
&nbsp;&nbsp;&nbsp;&nbsp;最常见的4字头Status Code，通常会自定义<br />
<strong>405     Method Not Allowed</strong><br />
&nbsp;&nbsp;&nbsp;&nbsp;response header需要包含Allow，列出支持的method<br />
<strong>406     Not Acceptable</strong><br />
&nbsp;&nbsp;&nbsp;&nbsp;response不被request header中的Accept做支持<br />
&nbsp;&nbsp;&nbsp;&nbsp;除了HEAD，response会给出包含更多信息的entity<br />
&nbsp;&nbsp;&nbsp;&nbsp;entity format由request header中的Content-Type决定<br />
<strong>407     Proxy Authentication Required</strong><br />
&nbsp;&nbsp;&nbsp;&nbsp;与401类似<br />
&nbsp;&nbsp;&nbsp;&nbsp;Proxy的response header必须包含Proxy-Authenticate<br />
<strong>408     Request Timeout<br />
409     Conflict</strong><br />
&nbsp;&nbsp;&nbsp;&nbsp;需要User干预解决<br />
&nbsp;&nbsp;&nbsp;&nbsp;在PUT的时候可能遇到<br />
<strong>410     Gone</strong><br />
&nbsp;&nbsp;&nbsp;&nbsp;URI已经不存在，且不提供3xx来重定向<br />
&nbsp;&nbsp;&nbsp;&nbsp;如果server没有足够的信息来判断URI的不存在是temporary还是permanent，可以用404代替<br />
<strong>411     Length Required</strong><br />
&nbsp;&nbsp;&nbsp;&nbsp;request header中缺少Content-Length<br />
<strong>412     Precondition Failed<br />
413     Request Entity Too Large</strong><br />
&nbsp;&nbsp;&nbsp;&nbsp;如果只是temporary，可以包含Retry-After，指定重试的时间间隔<br />
<strong>414     Request-URI Too Long</strong><br />
&nbsp;&nbsp;&nbsp;&nbsp;有几种可能导致这个返回码的情况<br />
&nbsp;&nbsp;&nbsp;&nbsp;将POST当成了GET<br />
&nbsp;&nbsp;&nbsp;&nbsp;循环重定向，每次都append上当前URI<br />
&nbsp;&nbsp;&nbsp;&nbsp;攻击<br />
<strong>415     Unsupported Media Type<br />
&nbsp;&nbsp;&nbsp;&nbsp;416     Requested Range Not Satisfiable</strong><br />
&nbsp;&nbsp;&nbsp;&nbsp;参考206<br />
<strong>417     Expectation Failed</strong><br />
&nbsp;&nbsp;&nbsp;&nbsp;不能满足request header中的Expect，参考100</p>
<h3>5xx     Server Error</h3>
<p><strong>500     Internal Server Error</strong><br />
&nbsp;&nbsp;&nbsp;&nbsp;在server没有输出正确的response header的时候会出现<br />
<strong>501     Not Implemented<br />
502     Bad Gateway</strong><br />
&nbsp;&nbsp;&nbsp;&nbsp;由gateway或者proxy返回，表明上游server不能返回请求的URI<br />
<strong>503     Service Unavailable</strong><br />
&nbsp;&nbsp;&nbsp;&nbsp;server可能过载，或者正在维护<br />
&nbsp;&nbsp;&nbsp;&nbsp;可以返回Retry-After，如果没有，则视作500<br />
<strong>504     Gateway Timeout</strong><br />
&nbsp;&nbsp;&nbsp;&nbsp;上游server不能及时返回<br />
<strong>505     HTTP Version Not Supported</strong></p>
]]></content:encoded>
			<wfw:commentRss>http://icomes.net/2009/10/12/rfc2616%e4%b8%ad%e5%85%b3%e4%ba%8ehttp-status-code%e7%9a%84%e5%ae%9a%e4%b9%89/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>读RFC2616</title>
		<link>http://icomes.net/2008/11/24/%e8%af%bbrfc2616/</link>
		<comments>http://icomes.net/2008/11/24/%e8%af%bbrfc2616/#comments</comments>
		<pubDate>Mon, 24 Nov 2008 14:42:00 +0000</pubDate>
		<dc:creator>梁剑</dc:creator>
				<category><![CDATA[Protocol]]></category>
		<category><![CDATA[技术笔记]]></category>
		<category><![CDATA[http rfc]]></category>

		<guid isPermaLink="false">http://tridot.cn/?p=199</guid>
		<description><![CDATA[想想做web已经一年半了，还没有系统的看过web的基础协议。
所以找了rfc2616的pdf版本，准备详细了解一下。
中文版也是有的，也曾下载看过，不过翻译质量实在不敢恭维。
还是和英文书一样，看原版吧。
非常有论文风格的一个标准。
一开始先是下定义，不过有几个定义我反复看了几次，还是不清楚具体的区别。
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 [...]]]></description>
			<content:encoded><![CDATA[<p>想想做web已经一年半了，还没有系统的看过web的基础协议。<br />
所以找了rfc2616的pdf版本，准备详细了解一下。</p>
<p>中文版也是有的，也曾下载看过，不过翻译质量实在不敢恭维。<br />
还是和英文书一样，看原版吧。</p>
<p>非常有论文风格的一个标准。<br />
一开始先是下定义，不过有几个定义我反复看了几次，还是不清楚具体的区别。</p>
<p style="padding-left: 30px;"><strong>proxy</strong><br />
An intermediary program which acts as both a server and a client for the purpose of making requests on behalf<br />
of other clients. Requests are serviced internally or by passing them on, with possible translation, to other<br />
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, protocolreduction, or anonymity filtering. Except where either transparent or non-transparent behavior is explicitly stated, the HTTP proxy requirements apply to both types of proxies.<br />
<strong>gateway</strong><br />
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<br />
communicating with a gateway.<br />
<strong>tunnel</strong><br />
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.</p>
<p>有些实际例子就好了。</p>
]]></content:encoded>
			<wfw:commentRss>http://icomes.net/2008/11/24/%e8%af%bbrfc2616/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
