Certain traffics get corrupted #1452

Closed
seanl-adg opened this Issue Dec 14, 2016 · 10 comments

Projects

None yet

5 participants

@seanl-adg

Original thread: https://forum.adguard.com/index.php?threads/electricquilt-com.17567/

STR:

  1. go to http://electricquilt.com/online-shop/electric-quilt-7/
  2. Select any option of the product (e.g. Mac Download $189.95)
  3. Click on "Add to Cart" button.

Then a browser tries to download an application/octet-stream file with no name.

  • This is reproduced with all browsers that I've tested.
  • Applying exception rules to certain requests does not resolve the problem.
  • If I exclude the browser from "filtered apps" section, the website works as intended.
  • If Fiddler is being openned and capturing traffics, the website works as intended.
@ameshkov ameshkov added this to the 6.2 milestone Dec 19, 2016
@ameshkov ameshkov added the Bug label Dec 19, 2016
@msigley
msigley commented Jan 23, 2017

Any progress on this? I have had this issue open in my internal bug tracker for over a month now.

@ameshkov ameshkov modified the milestone: 6.1 R3, 6.2 Jan 26, 2017
@adbuker adbuker was assigned by ameshkov Jan 26, 2017
@ameshkov ameshkov modified the milestone: 6.2, 6.1 R3 Jan 26, 2017
@ameshkov
Member

The server sends an invalid response.

Request:

POST electricquilt.com/online-shop/cart/ HTTP/1.1
Host: electricquilt.com
Connection: keep-alive
Content-Length: 114
Cache-Control: max-age=0
Origin: http://electricquilt.com
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36
Content-Type: application/x-www-form-urlencoded
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Referer: http://electricquilt.com/online-shop/electric-quilt-7/
Accept-Encoding: gzip, deflate
Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.6,en;q=0.4
Cookie: PHPSESSID=7rsj2u9fa1n8om6mhk4a8a76i3; funmodal-donot-show-again=0; flag-status=show

Response:

HTTP/1.1 302 Moved Temporarily
Cache-Control: no-cache
Pragma: no-cache
Content-Length: 0
Content-Type: text/html; charset=UTF-8
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Location: http://electricquilt.com/online-shop/cart/
Server: EQ Web Server
X-Pingback: http://electricquilt.com/xmlrpc.php
Refresh: 0;url=http://electricquilt.com/online-shop/cart/
X-Powered-By: Blood, Sweat, and Tears
Date: Thu, 26 Jan 2017 10:06:26 GMT

Content length should be zero, but then server sends response content:

<head><title>Document Moved</title></head>
<body><h1>Object Moved</h1>This document may be found <a HREF="http: //electricquilt.com/online-shop/cart/">here</a></body>
@ameshkov
Member

Possible solution: shut connection down in case of response violating HTTP protocol. We should think about other options though.

@confessor-adguard
Member

Please note that this problem affects Adguard for Mac too.

@ameshkov
Member

I guess it affects AG for Android as well.

@ameshkov ameshkov modified the milestone: 6.1 R3, 6.2 Feb 1, 2017
@adbuker
adbuker commented Feb 1, 2017

ADWIN-CR-122

@adbuker adbuker closed this Feb 1, 2017
@msigley
msigley commented Feb 1, 2017

So does this mean this issue is resolved?

The returning content on redirect responses is a default IIS + FastCGI behavior.

@ameshkov
Member
ameshkov commented Feb 1, 2017

So does this mean this issue is resolved?

Yeah, we'll handle it properly starting from v6.1R3.

The returning content on redirect responses is a default IIS + FastCGI behavior.

Returning content is not a problem.

What's wrong is that response headers contain Content-Length: 0 at the same time.

@msigley
msigley commented Feb 1, 2017

Well if you are emulating browser behavior. If the content length is 0 you simply ignore the content.

@ameshkov
Member
ameshkov commented Feb 2, 2017

Well if you are emulating browser behavior. If the content length is 0 you simply ignore the content.

The problem is that connection was kept alive.

Here's what happens inside of a single connection:

  1. Client: Sends request
  2. Client: Awaits for response
  3. Server: Sends response with Content-Length: 0
  4. Server: Sends response body
  5. Client: Reads response headers (not content as content length is 0)
  6. Client: Sends next request
  7. Client: Starts reading a response to the next request; gets previous response body instead; closes connection due to protocol violation.

Browser detects protocol violation earlier, in step 4. The problem was that with Adguard browser didn't know that server has violated protocol unless AG gets to step 7.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment