In the second setting we examined, in which a web application F/W is installed before the W/S, smuggling can bypass some of the F/W's web-application defenses. This is because the F/W does not apply some of its web application security rules to the smuggled request because it does not see it, as we explain below. This enables an attacker to smuggle in malicious requests (e.g., worm-like attacks, buffer overflows, etc.), which directly compromise the W/S security. Unlike the web cache poisoning attack in the first example, where the attacked entity is the cache server, in this case the attacked entity is the W/S itself.
In the third setting, in which clients use a proxy server that shares a TCP connection to the W/S, it is possible for one client (the attacker) to send a request to the W/S with a second client's credentials. It is also possible to exploit a vulnerability in the web application (using the same fundamental vulnerability used in cross-site scripting attacks, dubbed XSS [7,8]) to steal client credentials without the need to actually contact the client, making it a potentially stronger attack than cross-site scripting.

Example 1: web cache poisoning (HTTP REQUEST smuggling through a web cache server)
Our first example demonstrates a classic HRS attack. Suppose a POST request contains two "Content-Length" headers with conflicting values. Some servers (e.g., IIS and Apache) reject such a request, but it turns out that others choose to ignore the problematic header. Which of the two headers is the problematic one? Fortunately for the attacker, different servers choose different answers. For example, SunONE W/S 6.1 (SP1) uses the first "Content-Length" header, while SunONE Proxy 3.6 (SP4) takes the second header (notice that both applications are from the SunONE family). Let SITE be the DNS name of the SunONE W/S behind the SunONE Proxy. Suppose that "/poison.html" is a static (cacheable) HTML page on the W/S. Here's the HRS attack that exploits the inconsistency between the two servers:

1 POST http://SITE/foobar.html HTTP/1.1
2 Host: SITE
3 Connection: Keep-Alive
4 Content-Type: application/x-www-form-urlencoded
5 Content-Length: 0
6 Content-Length: 44
7 [CRLF]
8 GET /poison.html HTTP/1.1
9 Host: SITE
10 Bla: [space after the "Bla:", but no CRLF]
11 GET http://SITE/page_to_poison.html HTTP/1.1
12 Host: SITE
13 Connection: Keep-Alive
14 [CRLF]
[Note that each line terminates with a CRLF ("\r\n"), except for line 10.]
Let's examine what happens when this request is sent to the W/S via the proxy server. First, the proxy parses the POST request in lines 1-7 (in blue), and encounters the two "Content-Length" headers. As we mentioned earlier, it decides to ignore the first header, so it assumes the request has a body of length 44 bytes. Therefore, it treats the data in lines 8-10 as the first request body (lines 8-10, in purple, contain exactly 44 bytes). The proxy then parses lines 11-14 (in red), which it treats as the client's second request. Now let's see how the W/S interprets the same payload, once it has been forwarded to it by the proxy.
Unlike the proxy, the W/S uses the first "Content-Length" header: as far as it's concerned, the first POST request has no body, and the second request is the GET in line 8 (notice that the GET in line 11 is parsed by the W/S as the value of the "Bla" header in line 10). To summarize, this is how the data is partitioned by the two servers:
1st request 2nd request
SunONE Proxy lines 1-10 lines 11-14
SunONE W/S lines 1-7 lines 8-14
Next, let's see which responses are sent back to the client. The requests the W/S sees are "POST /foobar.html" (from line 1) and "GET /poison.html" (from line 8), so it sends back two responses with the contents of the "foobar.html" page and the "poison.html" page, respectively. The proxy matches these responses to the two requests it thinks were sent by the client - "POST /foobar.html" (line 1) and "GET /page_to_poison.html" (line 11). Since the response is cacheable (we assumed "poison.html" is a cacheable page), the proxy caches the contents of "poison.html" under the URL "page_to_poison.html", and voila the cache is poisoned! Any client requesting "page_to_poison.html" from the proxy would receive the "poison.html" page.
A technical note: Lines 1-10 and 11-14 have to be sent in two separate packets, since SunONE Proxy doesn't pipeline requests on the same packet.
Special cases:
More powerful attacks A much more powerful defacement can be achieved if the attacked site shares its IP address with another site (under the attacker's control) - as would typically be found in a shared (virtual) hosting scenario. In such a case, the proxy server may still share the TCP connection to the "server" (identified by its IP address) even though logically the traffic may be destined to different sites. The attacker then only needs to set up his/her own site (with the same IP address of the attacked site) and use a Host header (line 9) pointing at this site (e.g. "Host: evil.site"). Another variation is using a proxy request (assuming the backend web server is willing to serve it), i.e. at line 8, and sending GET http://evil.site/page.html ...
Both methods enable the attacker full control over the cached content.

For more examples see the full paper at: http://www.watchfire.com/resources/HTTP-Request-Smuggling.pdf