首先，这跟跨站是两回事。
HTTP Request Smuggling --- HRS
其原理是
client ----------> proxy server -----------> real web server
在这里，client提交HTTP包的时候，如果构造两个 Content-Length
而这两个Content-Length的值是冲突的，比如一个是0，一个是100
而proxy server 和 后面的 real web server 却解析了不同的 Content-Length
那么会造成什么呢？我们就有机会重定向client访问的页面！
ex:
POST http://SITE/foobar.html HTTP/1.1
Host: SITE
Connection: Keep-Alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 0
Content-Length: 44
[CRLF]
GET /poison.html HTTP/1.1
Host: SITE
Bla: [space after the "Bla:", but no CRLF]
GET http://SITE/page_to_poison.html HTTP/1.1
Host: SITE
Connection: Keep-Alive
[CRLF]
比如proxy读到了第2个content-length，丢弃了第一个，那么就正好读到bla后面
接下来的
GET http://SITE/page_to_poison.html HTTP/1.1
Host: SITE
Connection: Keep-Alive
[CRLF]
会被proxy当作是来自client的第二个包
而对于 real web server,如果他只读到了第一个 Content-Length,丢弃了第二个 Content-Length
那么，就会认为
GET /poison.html HTTP/1.1
Host: SITE
Bla: [space after the "Bla:", but no CRLF]
是client发来的第二个包，而
"GET http://SITE/page_to_poison.html HTTP/1.1 " 则会做为Bla的值，而被忽略掉
就是因为这个差异！！
因为两个server对Content-Length 的不同选择造成了HRS！
会发生什么呢？
假设proxy里是cache了poison.html的，在这里，就会把 page_to_poison.html 指向 posion.html的内容
这里是proxy来完成这个动作了
所以当client 通过proxy访问 page_to_poison.html 的时候，得到的却是posion的内容！
我们只发送了两次包，就控制了proxy的cache！
然而可惜的是，这里还有HOST字段，使得劫持与被劫持的页面只能位于同一IP上
具体proxy和webserver选择哪个Content-Length字段，要看具体的 Web Server了
CVE-2005-2088 描述了这一漏洞
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2088
要真正说利用，有几种方式：
1。突破虚拟主机
2。结合跨站，可以跨该机器上的任意一个页面
3。突破WEB防火墙和IPS
所以，HRS的本质和XSS是不一样的。