标签为 "Http" 的存档

三次握手的第三个ACK包丢了,TCP的处理方式

三次握手的第三个ACK包丢了——客户端认为连接建立,写数据时,会触发RST
当Client端收到Server的SYN+ACK应答后,其状态变为ESTABLISHED,并发送ACK包给Server;
如果此时ACK在网络中丢失,那么Server端该TCP连接的状态为SYN_RECV,并且依次等待3秒、6秒、12秒后重新发送SYN+ACK包,以便Client重新发送ACK包。
Server重发SYN+ACK包的次数,可以通过设置/proc/sys/net/ipv4/tcp_synack_retries修改,默认值为5。 如果重发指定次数后,仍然未收到ACK应答,那么一段时间后,Server自动关闭这个连接。
但是Client认为这个连接已经建立,如果Client端向Server写数据,Server端将以RST包响应,方能感知到Server的错误.

curl使用via的header时,不支持gzip

curl -s -H 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8' -H 'Accept-encoding: gzip,deflate' "http://m.news.haosou.com/" -H "Via: curl"  | gunzip -

使用这条命令去抓取页面, 不传递Via的header时,是能正常执行的,当带上via时,返回内容不再gzip,直接是正常文本。
查询了下相关资料,原来via参数在RFC里是有规范的,不是随便指定的。

见:http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.45


The Via general-header field MUST be used by gateways and proxies to indicate the intermediate protocols and recipients between the user agent and the server on requests, and between the origin server and the client on responses. It is analogous to the "Received" field of RFC 822 [9] and is intended to be used for tracking message forwards, avoiding request loops, and identifying the protocol capabilities of all senders along the request/response chain.

Via = "Via" ":" 1#( received-protocol received-by [ comment ] )
received-protocol = [ protocol-name "/" ] protocol-version
protocol-name = token
protocol-version = token
received-by = ( host [ ":" port ] ) | pseudonym
pseudonym = token
The received-protocol indicates the protocol version of the message received by the server or client along each segment of the request/response chain. The received-protocol version is appended to the Via field value when the message is forwarded so that information about the protocol capabilities of upstream applications remains visible to all recipients.

The protocol-name is optional if and only if it would be "HTTP". The received-by field is normally the host and optional port number of a recipient server or client that subsequently forwarded the message. However, if the real host is considered to be sensitive information, it MAY be replaced by a pseudonym. If the port is not given, it MAY be assumed to be the default port of the received-protocol.

Multiple Via field values represents each proxy or gateway that has forwarded the message. Each recipient MUST append its information such that the end result is ordered according to the sequence of forwarding applications.

Comments MAY be used in the Via header field to identify the software of the recipient proxy or gateway, analogous to the User-Agent and Server header fields. However, all comments in the Via field are optional and MAY be removed by any recipient prior to forwarding the message.

For example, a request message could be sent from an HTTP/1.0 user agent to an internal proxy code-named "fred", which uses HTTP/1.1 to forward the request to a public proxy at nowhere.com, which completes the request by forwarding it to the origin server at www.ics.uci.edu. The request received by www.ics.uci.edu would then have the following Via header field:

Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)
Proxies and gateways used as a portal through a network firewall SHOULD NOT, by default, forward the names and ports of hosts within the firewall region. This information SHOULD only be propagated if explicitly enabled. If not enabled, the received-by host of any host behind the firewall SHOULD be replaced by an appropriate pseudonym for that host.

For organizations that have strong privacy requirements for hiding internal structures, a proxy MAY combine an ordered subsequence of Via header field entries with identical received-protocol values into a single such entry. For example,

Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy
could be collapsed to
Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
Applications SHOULD NOT combine multiple entries unless they are all under the same organizational control and the hosts have already been replaced by pseudonyms. Applications MUST NOT combine entries which have different received-protocol values.

http请求头信息:If-Modified-Since

If-Modified-Since是标准的HTTP请求头标签,在发送HTTP请求时,把浏览器端缓存页面的最后修改时间一起发到服务器去,服务器会把这个时间与服务器上实际文件的最后修改时间进行比较。
在你的请求中发送一个 If-Modified-Since 头信息,它包含了上一次从服务器连同数据所获得的日期。如果数据从那时起没有改变,服务器将返回一个特殊的 HTTP 状态代码 304,这意味着 “从上一次请求后这个数据没有改变”。
当服务器发送状态编码 304 时,不再重新发送数据。您仅仅获得了这个状态代码。所以当数据没有更新时,你不需要一次又一次地下载相同的数据;服务器假定你有本地的缓存数据。

jQuery,IE7,url,www,http,A Bug

今天遇到一个怪事,在一个页面下, 有一个区域,用来动态的显示一些数据,主要是显示一个url,会使用jQuery去动态的改变a标签的属性,来显示相关信息。
但是却发现,在IE7下,当改变了a标签的属性之后,凡是www开头的url,显示文本都会添加一个http://,让人费解。
后来发现是一个小bug,但是不确定是jQuery还是IE7的问题。
解决方案就在设定A标签的属性的顺序上。

//当顺序为
this.linkElem.html(data.dspurl).attr('href', data.link).attr('title', data.link);
//时,就会发生以上怪现象,但是如果改变其顺序
this.linkElem.attr('href', data.link).attr('title', data.link).text(data.dspurl);
//就会正常了。

Read more…

HTTP 400 错误 – 请求无效 (Bad request)

HTTP 400 错误 – 请求无效 (Bad request)

介绍—http 400错误.

您的Web服务器认为客户端发送的数据流 (例如您的浏览器或我们的 CheckUpDown 机器人 ) 是 ‘ 畸形的’,即没有完全遵守 HTTP 协议。 因此您的 Web 服务器无法理解和处理该请求。

该错误几乎总是意味着客户端系统以及 / 或者您的Web服务器编程失败。

HTTP 循环中的 400 错误

任何客户端 ( 例如您的浏览器或我们的 CheckUpDown 机器人 ) ,都需要通过以下循环:

从您站点的 IP 名称 ( 即您站点的网址-URL, 不带起始的 ‘http://’) 获得一个 IP 地址。这个对应关系 ( 即由 IP 名称向 IP 地址转换的对应关系 ) 由域名服务器 (DNSs) 提供。
打开一个 IP 套接字 (socket) 连接到该 IP 地址。
通过该套接字写 HTTP 数据流。
从您的Web服务器接受响应的 HTTP 数据流。该数据流包括状态编码, 其值取决于 HTTP 协议 。 解析该数据流得到 状态编码和其他有用信息。
该错误在以上所述的最后一步生成,即当客户端收到 HTTP 状态编码并识别其为 ‘ 400’ 时

解决 400 错误 – 一般方法

在客户端或是Web服务器,或者两端都存在一个低层程序漏洞 (bug) 。 如果您无法进入这些系统的源程序, 您唯一能做的是把该问题提交给开发这些系统的公司的技术支持人员。

Read more…

Nginx出现“413 Request Entity Too Large”错误解决方法

在使用curl上传POST一段数据时,被提示413 Request Entity Too Large,应该是nginx限制了上传数据的大小。
解决方法就是
打开nginx主配置文件nginx.conf,一般在/usr/local/nginx/conf/nginx.conf这个位置,找到http{}段,修改或者添加

client_max_body_size 2m;

然后重启nginx,

sudo /etc/init.d/nginxd reload

即可。
要是以php运行的话,这个大小client_max_body_size要和php.ini中的如下值的最大值差不多或者稍大,这样就不会因为提交数据大小不一致出现错误。

post_max_size = 2M
upload_max_filesize = 2M

Read more…

【ASP.net文档】用C#实现HTTP协议下的多线程文件传输

很多人都有过使用网络蚂蚁或网络快车软件下载互联网文件的经历,这些软件的使用可以大大加速互联网上文件的传输速度,减少文件传输的时间。这些软件为什么有如此大的魔力呢?其主要原因是这些软件都采用了多线程下载和断点续传技术。如果我们自己来编写一个类似这样的程序,也能够快速的在互联网上下载文件,那一定是非常愉快的事情。下面介绍一下如何利用C#语言编写一个支持多线程下载文件的程序,你会看到利用C#语言编写网络应程序是多么的容易,从中也能体会到C#语言中强大的网络功能。

首先介绍一下HTTP协议,HTTP亦即Hpyer Text Transfer Protocal的缩写,它是现代互联网上最重要的一种网络协议,超文本传输协议位于TCP/IP协议的应用层,是一个面向无连接、简单、快速的C/S结构的协议。HTTP的工作过程大体上分连接、请求、响应和断开连接四个步骤。C#语言对HTTP协议提供了良好的支持,在.NET类库中提供了WebRequest和WebResponse类,这两个类都包含在System.Net命名空间中,利用这两个类可以实现很多高级的网络功能,本文中多线程文件下载就是利用这两个类实现的。 WebRequest和WebResponse都是抽象基类,因此在程序中不能直接作为对象使用,必须被继承,实际使用中,可根据URI参数中的URI前缀选用它们合适的子类,对于HTTP这类URI,HttpWebRequest和HttpWebResponse类可以用于处理客户程序同WEB服务器之间的HTTP通讯。

Read more…

ASP –HTTP 错误 405 – 禁止访问资源 的解决办法

HTTP 错误 405 - 禁止访问资源

HTTP 错误 405 - 禁止访问资源

本地调试IIS时,在提交页面信息出现:HTTP 错误 405 – 禁止访问资源 的解决办法!
Read more…